1
2
3
4
5
6
7Internet Engineering Task Force (IETF) J. Yao
8Request for Comments: 6531 W. Mao
9Obsoletes: 5336 CNNIC
10Category: Standards Track February 2012
11ISSN: 2070-1721
12
13
14 SMTP Extension for Internationalized Email
15
16Abstract
17
18 This document specifies an SMTP extension for transport and delivery
19 of email messages with internationalized email addresses or header
20 information.
21
22Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc6531.
35
36Copyright Notice
37
38 Copyright (c) 2012 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
40
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
50
51 This document may contain material from IETF Documents or IETF
52 Contributions published or made publicly available before November
53 10, 2008. The person(s) controlling the copyright in some of this
54 material may not have granted the IETF Trust the right to allow
55
56
57
58Yao & Mao Standards Track [Page 1]
59
60RFC 6531 SMTP Extension for SMTPUTF8 February 2012
61
62
63 modifications of such material outside the IETF Standards Process.
64 Without obtaining an adequate license from the person(s) controlling
65 the copyright in such materials, this document may not be modified
66 outside the IETF Standards Process, and derivative works of it may
67 not be created outside the IETF Standards Process, except to format
68 it for publication as an RFC or to translate it into languages other
69 than English.
70
71Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
75 1.2. Changes Made to Other Specifications . . . . . . . . . . . 3
76 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
77 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
78 3.1. Framework for the Internationalization Extension . . . . . 4
79 3.2. The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . . 5
80 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
81 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 8
82 3.5. Non-ASCII Addresses and Reply-Codes . . . . . . . . . . . 9
83 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9
84 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
85 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
86 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10
87 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
88 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
90 4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13
91 4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
92 4.3. WITH Protocol Types Sub-Registry of the Mail
93 Transmission Types Registry . . . . . . . . . . . . . . . 15
94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
95 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
98 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114Yao & Mao Standards Track [Page 2]
115
116RFC 6531 SMTP Extension for SMTPUTF8 February 2012
117
118
1191. Introduction
120
121 The document defines a Simple Mail Transfer Protocol [RFC5321]
122 extension so servers can advertise the ability to accept and process
123 internationalized email addresses (see Section 1.1) and
124 internationalized email headers [RFC6532].
125
126 An extended overview of the extension model for internationalized
127 email addresses and the email header appears in RFC 6530 [RFC6530],
128 referred to as "the framework document" in this specification. A
129 thorough understanding of the information in that document and in the
130 base Internet email specifications [RFC5321] [RFC5322] is necessary
131 to understand and implement this specification.
132
1331.1. Terminology
134
135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137 document are to be interpreted as described in RFC 2119 [RFC2119].
138
139 The terms "UTF-8 string" or "UTF-8 character" are used to refer to
140 Unicode characters, which may or may not be members of the ASCII
141 subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All
142 other specialized terms used in this specification are defined in the
143 framework document or in the base Internet email specifications. In
144 particular, the terms "ASCII address", "internationalized email
145 address", "non-ASCII address", "SMTPUTF8", "internationalized
146 message", and "message" are used in this document according to the
147 definitions in the framework document [RFC6530].
148
149 Strings referred to in this document, including ASCII strings, MUST
150 be expressed in UTF-8.
151
152 This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some
153 basic rules in this document are identified in Section 3.3 as being
154 defined (under the same names) in RFC 5234 [RFC5234], RFC 5321
155 [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532].
156
1571.2. Changes Made to Other Specifications
158
159 This specification extends some syntax rules defined in RFC 5321 and
160 permits internationalized email addresses in the envelope and in
161 trace fields, but it does not modify RFC 5321. It permits data
162 formats defined in RFC 6532 [RFC6532], but it does not modify RFC
163 5322. It does require that the 8BITMIME extension [RFC6152] be
164 announced by the SMTPUTF8-aware SMTP server and used with
165 "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not
166 modify the 8BITMIME specification in any way.
167
168
169
170Yao & Mao Standards Track [Page 3]
171
172RFC 6531 SMTP Extension for SMTPUTF8 February 2012
173
174
175 This specification replaces an earlier, experimental, approach to the
176 same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes
177 the changes in approach between RFC 5336 [RFC5336] and this
178 specification. Anyone trying to convert an implementation from the
179 experimental specification to the specification in this document will
180 need to review those changes carefully.
181
1822. Overview of Operation
183
184 This document specifies an element of the email internationalization
185 work, specifically the definition of an SMTP extension for
186 internationalized email. The extension is identified with the token
187 "SMTPUTF8".
188
189 The internationalized email headers specification [RFC6532] provides
190 the details of email header features enabled by this extension.
191
1923. Mail Transport-Level Protocol
193
1943.1. Framework for the Internationalization Extension
195
196 The following service extension is defined:
197
198 1. The name of the SMTP service extension is "Internationalized
199 Email".
200
201 2. The EHLO keyword value associated with this extension is ../smtpserver/server.go:914
202 "SMTPUTF8".
203
204 3. No parameter values are defined for this EHLO keyword value. In
205 order to permit future (although unanticipated) extensions, the
206 EHLO response MUST NOT contain any parameters for this keyword.
207 The SMTPUTF8-aware SMTP client MUST ignore any parameters if ../smtpclient/client.go:743
208 they appear for this keyword; that is, the SMTPUTF8-aware SMTP
209 client MUST behave as if the parameters do not appear. If an
210 SMTP server includes SMTPUTF8 in its EHLO response, it MUST be
211 fully compliant with this version of this specification.
212
213 4. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. ../smtpclient/client.go:1172 ../smtpserver/server.go:1436
214 The parameter does not accept a value. If this parameter is set
215 in the MAIL command, it indicates that the SMTP client is
216 SMTPUTF8-aware. Its presence also asserts that the envelope
217 includes the non-ASCII address, the message being sent is an
218 internationalized message, or the message being sent needs the
219 SMTPUTF8 support.
220
221
222
223
224
225
226Yao & Mao Standards Track [Page 4]
227
228RFC 6531 SMTP Extension for SMTPUTF8 February 2012
229
230
231 5. The maximum length of a MAIL command line is increased by 10 5321:3500 4954:134 1870:92 6152:90 ../smtpserver/server.go:1350
232 characters to accommodate the possible addition of the SMTPUTF8
233 parameter.
234
235 6. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY)
236 and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not
237 accept a value. The parameter indicates that the SMTP client
238 can accept Unicode characters in UTF-8 encoding in replies from
239 the VRFY and EXPN commands.
240
241 7. No additional SMTP verbs are defined by this extension.
242
243 8. Servers offering this extension MUST provide support for, and
244 announce, the 8BITMIME extension [RFC6152].
245
246 9. The reverse-path and forward-path of the SMTP MAIL and RCPT
247 commands are extended to allow Unicode characters encoded in
248 UTF-8 in mailbox names (addresses).
249
250 10. The mail message body is extended as specified in RFC 6532
251 [RFC6532].
252
253 11. The SMTPUTF8 extension is valid on the submission port
254 [RFC6409]. It may also be used with the Local Mail Transfer
255 Protocol (LMTP) [RFC2033]. When these protocols are used, their
256 use should be reflected in the trace field WITH keywords as
257 appropriate [RFC3848].
258
2593.2. The SMTPUTF8 Extension
260
261 An SMTP server that announces the SMTPUTF8 extension MUST be prepared
262 to accept a UTF-8 string [RFC3629] in any position in which RFC 5321
263 specifies that a <mailbox> can appear. Although the characters in
264 the <local-part> are permitted to contain non-ASCII characters, the
265 actual parsing of the <local-part> and the delimiters used are
266 unchanged from the base email specification [RFC5321]. Any domain
267 name to be looked up in the DNS MUST conform to and be processed as
268 specified for Internationalizing Domain Names in Applications (IDNA)
269 [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or
270 server MUST either use a Unicode-aware DNS library, or transform the
271 internationalized domain name to A-label form (i.e., a fully-
272 qualified domain name that contains one or more A-labels but no
273 U-labels) as specified in RFC 5890 [RFC5890].
274
275 An SMTP client that receives the SMTPUTF8 extension keyword in
276 response to the EHLO command MAY transmit mailbox names within SMTP
277 commands as internationalized strings in UTF-8 form. It MAY send a
278 UTF-8 header [RFC6532] (which may also include mailbox names in
279
280
281
282Yao & Mao Standards Track [Page 5]
283
284RFC 6531 SMTP Extension for SMTPUTF8 February 2012
285
286
287 UTF-8). It MAY transmit the domain parts of mailbox names within
288 SMTP commands or the message header as A-labels or U-labels
289 [RFC5890]. The presence of the SMTPUTF8 extension does not change
290 the server-relaying behaviors described in RFC 5321.
291
292 If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the
293 SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized
294 email address and MUST NOT transmit a mail message containing
295 internationalized mail headers as described in RFC 6532 [RFC6532] at
296 any level within its MIME structure [RFC2045]. (For this paragraph,
297 the internationalized domain name in A-label form as specified in
298 IDNA definitions [RFC5890] is not considered to be
299 "internationalized".) Instead, if an SMTPUTF8-aware SMTP client
300 (sender) attempts to transfer an internationalized message and
301 encounters an SMTP server that does not support the extension, the
302 best action for it to take depends on other conditions. In
303 particular:
304
305 o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it
306 MAY choose its own way to deal with this scenario using the wide
307 discretion for changing addresses or otherwise fixing up and
308 transforming messages allowed by RFC 6409. As long as the
309 resulting message conforms to the requirements of RFC 5321 (i.e.,
310 without the SMTPUTF8 extension), the details of that
311 transformation are outside the scope of this document.
312
313 o If it is not an MSA or is an MSA and does not choose to transform ../smtpclient/client.go:1147
314 the message to one that does not require the SMTPUTF8 extension,
315 it SHOULD reject the message. As usual, this can be done either
316 by generating an appropriate reply during the SMTP transaction or
317 by accepting the message and then generating and transmitting a
318 non-delivery notification. If the latter choice is made, the
319 notification process MUST conform to the requirements of RFC 5321,
320 RFC 3464 [RFC3464], and RFC 6533 [RFC6533].
321
322 o As specified in Section 2.2.3 of RFC 5321, an SMTP client with
323 additional information and/or knowledge of special circumstances
324 MAY choose to requeue the message and try later and/or try an
325 alternate MX host as specified in that section.
326
327 This document applies when an SMTPUTF8-aware SMTP client or server
328 supports the SMTPUTF8 extension. For all other cases, and for
329 addresses and messages that do not require an SMTPUTF8 extension,
330 SMTPUTF8-aware SMTP clients and servers do not change the behavior
331 specified in RFC 5321 [RFC5321].
332
333
334
335
336
337
338Yao & Mao Standards Track [Page 6]
339
340RFC 6531 SMTP Extension for SMTPUTF8 February 2012
341
342
343 If an SMTPUTF8-aware SMTP server advertises the Delivery Status
344 Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533
345 [RFC6533].
346
3473.3. Extended Mailbox Address Syntax
348
349 RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely
350 in terms of ASCII characters. This document extends <Mailbox> to add
351 support of non-ASCII characters.
352
353 The key changes made by this specification include:
354
355 o The <Mailbox> ABNF rule is imported from RFC 5321 and updated in
356 order to support the internationalized email address. Other
357 related rules are imported from RFC 5321, RFC 5234, RFC 5890, and
358 RFC 6532, or are extended in this document.
359
360 o The definition of <sub-domain> is extended to permit both the RFC
361 5321 definition and a UTF-8 string in a DNS label that conforms
362 with IDNA definitions [RFC5890].
363
364 o The definition of <atext> is extended to permit both the RFC 5321
365 definition and a UTF-8 string. That string MUST NOT contain any
366 of the ASCII graphics or control characters.
367
368 The following ABNF rules imported from RFC 5321, Section 4.1.2, are
369 updated directly or indirectly by this document:
370
371 o <Mailbox>
372
373 o <Local-part>
374
375 o <Dot-string>
376
377 o <Quoted-string>
378
379 o <QcontentSMTP>
380
381 o <Domain>
382
383 o <Atom>
384
385 The following ABNF rule will be imported from RFC 6532, Section 3.1,
386 directly:
387
388 o <UTF8-non-ascii>
389
390
391
392
393
394Yao & Mao Standards Track [Page 7]
395
396RFC 6531 SMTP Extension for SMTPUTF8 February 2012
397
398
399 The following ABNF rule will be imported from RFC 5234, Appendix B.1,
400 directly:
401
402 o <DQUOTE>
403
404 The following ABNF rule will be imported from RFC 5890, Section
405 2.3.2.1, directly:
406
407 o <U-label>
408
409 The following rules are extended in ABNF [RFC5234] as follows.
410
411 sub-domain =/ U-label 5321:2303 ../message/authresults.go:473 ../smtpserver/parse.go:264
412 ; extend the definition of sub-domain in RFC 5321, Section 4.1.2
413
414 atext =/ UTF8-non-ascii 5321:2322 5321:2320 ../smtp/address.go:27 ../smtpserver/parse.go:412
415 ; extend the implicit definition of atext in
416 ; RFC 5321, Section 4.1.2, which ultimately points to
417 ; the actual definition in RFC 5322, Section 3.2.3
418
419 qtextSMTP =/ UTF8-non-ascii 5321:2332 ../smtpserver/parse.go:378
420 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2
421
422 esmtp-value =/ UTF8-non-ascii 5321:2281 ../smtpserver/parse.go:441
423 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2
424
4253.4. MAIL Command Parameter Usage
426
427 If the envelope or message being sent requires the capabilities of
428 the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply
429 the SMTPUTF8 parameter with the MAIL command. If this parameter is
430 provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP
431 client is aware that neither the envelope nor the message being sent
432 requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT
433 supply the SMTPUTF8 parameter with the MAIL command.
434
435 Because there is no guarantee that a next-hop SMTP server will
436 support the SMTPUTF8 extension, use of the SMTPUTF8 extension always
437 carries a risk of transmission failure. In fact, during the early
438 stages of deployment for the SMTPUTF8 extension, the risk will be
439 quite high. Hence, there is a distinct near-term advantage for
440 ASCII-only messages to be sent without using this extension. The
441 long-term advantage of casting ASCII [ASCII] characters (0x7f and
442 below) as UTF-8 form is that it permits pure-Unicode environments.
443
444
445
446
447
448
449
450Yao & Mao Standards Track [Page 8]
451
452RFC 6531 SMTP Extension for SMTPUTF8 February 2012
453
454
4553.5. Non-ASCII Addresses and Reply-Codes
456
457 An SMTPUTF8-aware SMTP client MUST NOT send an internationalized
458 message to an SMTP server that does not support SMTPUTF8. If the
459 SMTP server does not support this option, then the SMTPUTF8-aware
460 SMTP client has three choices according to Section 3.2 of this
461 specification.
462
463 The three-digit reply-codes used in this section are based on their
464 meanings as defined in RFC 5321.
465
466 When messages are rejected because the RCPT command requires an ASCII ../smtpserver/parse.go:68 ../smtpserver/parse.go:212
467 address, the reply-code 553 is returned with the meaning "mailbox
468 name not allowed". When messages are rejected because the MAIL ../smtpserver/parse.go:203
469 command requires an ASCII address, the reply-code 550 is returned
470 with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP
471 server supports enhanced mail system status codes [RFC3463], reply-
472 code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII
473 addresses not permitted for that sender/recipient".
474
475 When messages are rejected for other reasons, the server follows the
476 model of the base email specification in RFC 5321; this extension
477 does not change those circumstances or reply messages.
478
479 If a message is rejected after the final "." of the DATA command
480 because one or more recipients are unable to accept and process a
481 message with internationalized email headers, the reply-code "554" is
482 used with the meaning "Transaction failed". If the SMTPUTF8-aware
483 SMTP server supports enhanced mail system status codes [RFC3463],
484 reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this
485 condition, meaning "UTF-8 header message cannot be transmitted to one
486 or more recipients, so the message must be rejected".
487
488 The SMTPUTF8-aware SMTP servers are encouraged to detect that
489 recipients cannot accept internationalized messages and generate an
490 error after the RCPT command rather than waiting until after the DATA
491 command to issue an error.
492
4933.6. Body Parts and SMTP Extensions
494
495 The MAIL command parameter SMTPUTF8 asserts that a message is an
496 internationalized message or the message being sent needs the
497 SMTPUTF8 support. There is still a chance that a message being sent ../smtpserver/server.go:1680
498 via the MAIL command with the SMTPUTF8 parameter is not an
499 internationalized message. An SMTPUTF8-aware SMTP client or server
500 that requires accurate knowledge of whether a message is
501 internationalized needs to parse all message header fields and MIME
502
503
504
505
506Yao & Mao Standards Track [Page 9]
507
508RFC 6531 SMTP Extension for SMTPUTF8 February 2012
509
510
511 header fields [RFC2045] in the message body. However, this
512 specification does not require that the SMTPUTF8-aware SMTP client or
513 server inspects the message.
514
515 Although this specification requires that SMTPUTF8-aware SMTP servers
516 support the 8BITMIME extension [RFC6152] to ensure that servers have
517 adequate handling capability for 8-bit data, it does not require non-
518 ASCII body parts in the MIME message as specified in RFC 2045. The
519 SMTPUTF8 extension MAY be used as follows (assuming it is appropriate
520 given the body content):
521
522 - with the BODY=8BITMIME parameter [RFC6152], or
523
524 - with the BODY=BINARYMIME parameter, if the SMTP server advertises
525 BINARYMIME [RFC3030].
526
5273.7. Additional ESMTP Changes and Clarifications
528
529 The information carried in the mail transport process involves
530 addresses ("mailboxes") and domain names in various contexts in
531 addition to the MAIL and RCPT commands and extended alternatives to
532 them. In general, the rule is that, when RFC 5321 specifies a
533 mailbox, this SMTP extension requires UTF-8 form to be used for the
534 entire string. When RFC 5321 specifies a domain name, the
535 internationalized domain name SHOULD be in U-label form if the
536 SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label
537 form.
538
539 The following subsections list and discuss all of the relevant cases.
540
5413.7.1. The Initial SMTP Exchange
542
543 When an SMTP connection is opened, the SMTP server sends a "greeting"
544 response consisting of the 220 reply-code and some information. The
545 SMTP client then sends the EHLO command. Since the SMTP client
546 cannot know whether the SMTP server supports SMTPUTF8 until after it
547 receives the response to the EHLO, the SMTPUTF8-aware SMTP client
548 MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the
549 EHLO command. If the SMTPUTF8-aware SMTP server provides domain
550 names in the EHLO response, they MUST be in the form of LDH labels or
551 A-labels.
552
5533.7.2. Mail eXchangers
554
555 If multiple DNS MX records are used to specify multiple servers for a todo: ../queue/direct.go:198
556 domain (as described in Section 5 of RFC 5321 [RFC5321]), it is
557 strongly advised that all or none of them SHOULD support the SMTPUTF8
558
559
560
561
562Yao & Mao Standards Track [Page 10]
563
564RFC 6531 SMTP Extension for SMTPUTF8 February 2012
565
566
567 extension. Otherwise, unexpected rejections can happen during
568 temporary or permanent failures, which users might perceive as
569 serious reliability issues.
570
5713.7.3. Trace Information
572
573 The trace information <Return-path-line>, <Time-stamp-line>, and
574 their related rules are defined in Section 4.4 of RFC 5321 [RFC5321].
575 This document updates <Mailbox> and <Domain> to support non-ASCII
576 characters. When the SMTPUTF8 extension is used, the 'Reverse-path'
577 clause of the Return-path-line may include an internationalized
578 domain name that uses the U-label form. Also, the 'Stamp' clause of 5321:3311 ../smtpserver/server.go:1846
579 the Time-stamp-line may include an internationalized domain name that
580 uses the U-label form.
581
582 If the messages that include trace fields are sent by an SMTPUTF8-
583 aware SMTP client or relay server without the SMTPUTF8 parameter
584 included in the MAIL commands, trace field values must conform to RFC
585 5321 regardless of the SMTP server's capability.
586
587 When an SMTPUTF8-aware SMTP server adds a trace field to a message
588 that was or will be transmitted with the SMTPUTF8 parameter included
589 in the MAIL commands, that server SHOULD use the U-label form for
590 internationalized domain names in the new trace field.
591
592 The protocol value of the 'WITH' clause when this extension is used
593 is one of the SMTPUTF8 values specified in the "IANA Considerations"
594 section of this document.
595
5963.7.4. UTF-8 Strings in Replies
597
5983.7.4.1. MAIL Command
599
600 If an SMTP client follows this specification and sends any MAIL
601 commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP
602 server is permitted to use UTF-8 characters in the email address
603 associated with 251 and 551 reply-codes, and the SMTP client MUST be
604 able to accept and process them. If a given MAIL command does not
605 include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST
606 NOT return a 251 or 551 response containing a non-ASCII mailbox.
607 Instead, it MUST transform such responses into 250 or 550 responses
608 that do not contain non-ASCII addresses.
609
6103.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter
611
612 If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN
613 commands, it indicates that the SMTP client can accept UTF-8 strings
614 in replies to those commands. The parameter with the VRFY and EXPN
615
616
617
618Yao & Mao Standards Track [Page 11]
619
620RFC 6531 SMTP Extension for SMTPUTF8 February 2012
621
622
623 commands SHOULD only be used after the SMTP client sees the EHLO
624 response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware
625 SMTP server to use UTF-8 strings in mailbox names and full names that
626 occur in replies, without concern that the SMTP client might be
627 confused by them. An SMTP client that conforms to this specification
628 MUST accept and correctly process replies to the VRFY and EXPN
629 commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP
630 server MUST NOT use UTF-8 strings in replies if the SMTP client does
631 not specifically allow such replies by transmitting this parameter
632 with the VRFY and EXPN commands.
633
634 Most replies do not require that a mailbox name be included in the
635 returned text, and therefore a UTF-8 string is not needed in them.
636 Some replies, notably those resulting from successful execution of
637 the VRFY and EXPN commands, do include the mailbox.
638
639 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
640
641 vrfy = "VRFY" SP String 5321:2119 ../smtpserver/server.go:3317
642 [ SP "SMTPUTF8" ] CRLF
643 ; String may include Non-ASCII characters
644
645 expn = "EXPN" SP String 5321:2149 ../smtpserver/server.go:3336
646 [ SP "SMTPUTF8" ] CRLF
647 ; String may include Non-ASCII characters
648
649 The SMTPUTF8 parameter does not accept a value. If the reply to a
650 VRFY or EXPN command requires a UTF-8 string, but the SMTP client did
651 not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server
652 MUST use either the reply-code 252 or 550. Reply-code 252, defined
653 in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the
654 message and attempt the delivery". Reply-code 550, also defined in
655 RFC 5321 [RFC5321], means "Requested action not taken: mailbox
656 unavailable". When the SMTPUTF8-aware SMTP server supports enhanced
657 mail system status codes [RFC3463], the enhanced reply-code as
658 specified below is used. Using the SMTPUTF8 parameter with a VRFY or
659 EXPN command enables UTF-8 replies for that command only.
660
661 If a normal success response (i.e., 250) is returned, the response
662 MAY include the full name of the user and MUST include the mailbox of
663 the user. It MUST be in either of the following forms:
664
665 User Name <Mailbox>
666 ; Mailbox is defined in Section 3.3 of this document.
667 ; User Name can contain non-ASCII characters.
668
669 Mailbox
670 ; Mailbox is defined in Section 3.3 of this document.
671
672
673
674Yao & Mao Standards Track [Page 12]
675
676RFC 6531 SMTP Extension for SMTPUTF8 February 2012
677
678
679 If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not
680 allowed in the reply, and the SMTPUTF8-aware SMTP server supports
681 enhanced mail system status codes [RFC3463], the enhanced reply-code
682 is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a
683 UTF-8 string is required to show the mailbox name, but that form of
684 response is not permitted by the SMTP client".
685
686 If the SMTP client does not support the SMTPUTF8 extension, but
687 receives a UTF-8 string in a reply, it may not be able to properly
688 report the reply to the user, and some clients might mishandle that
689 reply. Internationalized messages in replies are only allowed in the
690 commands under the situations described above.
691
692 Although UTF-8 strings are needed to represent email addresses in
693 responses under the rules specified in this section, this extension
694 does not permit the use of UTF-8 strings for any other purposes.
695 SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in
696 replies except in the limited cases specifically permitted in this
697 section.
698
6994. IANA Considerations
700
7014.1. SMTP Service Extensions Registry
702
703 IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension"
704 registry of the "Mail Parameters" registry, according to the
705 following data:
706
707 +----------+---------------------------------+-----------+
708 | Keywords | Description | Reference |
709 +----------+---------------------------------+-----------+
710 | SMTPUTF8 | Internationalized email address | [RFC6531] |
711 +----------+---------------------------------+-----------+
712
7134.2. SMTP Enhanced Status Code Registry
714
715 The code definitions in this document replace those specified in RFC
716 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this
717 document, and based on RFC 5248 [RFC5248]. IANA has updated the
718 "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry"
719 with the following data:
720
721
722
723
724
725
726
727
728
729
730Yao & Mao Standards Track [Page 13]
731
732RFC 6531 SMTP Extension for SMTPUTF8 February 2012
733
734
735 Code: X.6.7 ../smtp/codes.go:114
736 Sample Text: Non-ASCII addresses not permitted for that
737 sender/recipient
738 Associated basic status code: 550, 553
739 Description: This indicates the reception of a MAIL or RCPT command
740 that non-ASCII addresses are not permitted.
741 Defined: RFC 6531 (Standards Track)
742 Submitter: Jiankang YAO
743 Change controller: ima@ietf.org
744
745
746 Code: X.6.8 ../smtp/codes.go:115
747 Sample Text: UTF-8 string reply is required, but not permitted by
748 the SMTP client
749 Associated basic status code: 252, 550, 553
750 Description: This indicates that a reply containing a UTF-8 string
751 is required to show the mailbox name, but that form of
752 response is not permitted by the SMTP client.
753 Defined: RFC 6531 (Standards Track)
754 Submitter: Jiankang YAO
755 Change controller: ima@ietf.org
756
757
758 Code: X.6.9 ../smtp/codes.go:116
759 Sample Text: UTF-8 header message cannot be transferred to one or
760 more recipients, so the message must be rejected
761 Associated basic status code: 550
762 Description: This indicates that transaction failed after the
763 final "." of the DATA command.
764 Defined: RFC 6531 (Standards Track)
765 Submitter: Jiankang YAO
766 Change controller: ima@ietf.org
767
768
769 Code: X.6.10
770 Description: This is a duplicate of X.6.8 and is thus deprecated.
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786Yao & Mao Standards Track [Page 14]
787
788RFC 6531 SMTP Extension for SMTPUTF8 February 2012
789
790
7914.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types 3848:34 ../smtpserver/server.go:1894
792 Registry
793
794 IANA has modified or added the following entries in the "WITH
795 protocol types" sub-registry under the "Mail Transmission Types"
796 registry.
797
798 +--------------+------------------------------+---------------------+
799 | WITH | Description | Reference |
800 | protocol | | |
801 | types | | |
802 +--------------+------------------------------+---------------------+
803 | UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] |
804 | UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
805 | UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
806 | | STARTTLS | |
807 | UTF8SMTPSA | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
808 | | STARTTLS and AUTH | [RFC6531] |
809 | UTF8LMTP | LMTP with SMTPUTF8 | [RFC6531] |
810 | UTF8LMTPA | LMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
811 | UTF8LMTPS | LMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
812 | | STARTTLS | |
813 | UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
814 | | STARTTLS and AUTH | [RFC6531] |
815 +--------------+------------------------------+---------------------+
816
8175. Security Considerations
818
819 The extended security considerations discussion in the framework
820 document [RFC6530] applies here.
821
822 More security considerations are discussed below:
823
824 Beyond the use inside the email global system (in SMTP envelopes and
825 message headers), internationalized email addresses will also show up
826 inside other cases, in particular:
827
828 o the logging systems of SMTP transactions and other logs to monitor
829 the email systems;
830
831 o the trouble ticket systems used by security teams to manage
832 security incidents, when an email address is involved;
833
834 In order to avoid problems that could cause loss of data, this will
835 likely require extending these systems to support full UTF-8, or
836 require providing an adequate mechanism for mapping non-ASCII strings
837 to ASCII.
838
839
840
841
842Yao & Mao Standards Track [Page 15]
843
844RFC 6531 SMTP Extension for SMTPUTF8 February 2012
845
846
847 Another security aspect to be considered is related to the ability by
848 security team members to quickly understand, read, and identify email
849 addresses from the logs, when they are tracking an incident.
850 Mechanisms to automatically and quickly provide the origin or
851 ownership of an internationalized email address SHALL be implemented
852 for use by log readers that cannot easily read non-ASCII information.
853
854 The SMTP commands VRFY and EXPN are sometimes used in SMTP
855 transactions where there is no message to transfer (by tools used to
856 take automated actions in case potential spam messages are
857 identified). Sections 3.5 and 7.3 of RFC 5321 give detailed
858 descriptions of use and possible behaviors. Implementation of
859 internationalized addresses can also affect logs and actions by these
860 tools.
861
8626. Acknowledgements
863
864 This document revises RFC 5336 [RFC5336] based on the result of the
865 Email Address Internationalization (EAI) working group's discussion.
866 Many EAI working group members did tests and implementations to move
867 this document to the Standards Track. Significant comments and
868 suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO,
869 Yoshiro YONEYA, and other members of JET and were incorporated into
870 the specification. Additional important comments and suggestions,
871 and often specific text, were contributed by many members of the
872 working group and design team. Those contributions include material
873 from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit
874 Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung,
875 Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey
876 Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele,
877 Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars
878 Eggert. Of course, none of the individuals are necessarily
879 responsible for the combination of ideas represented here.
880
881 Thanks a lot to Dave Crocker for his comments and helping with ABNF
882 refinement.
883
8847. References
885
8867.1. Normative References
887
888 [ASCII] American National Standards Institute (formerly United
889 States of America Standards Institute), "USA Code for
890 Information Interchange", ANSI X3.4-1968, 1968.
891
892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
893 Requirement Levels", BCP 14, RFC 2119, March 1997.
894
895
896
897
898Yao & Mao Standards Track [Page 16]
899
900RFC 6531 SMTP Extension for SMTPUTF8 February 2012
901
902
903 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
904 Extension for Delivery Status Notifications (DSNs)",
905 RFC 3461, January 2003.
906
907 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
908 RFC 3463, January 2003.
909
910 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
911 for Delivery Status Notifications", RFC 3464,
912 January 2003.
913
914 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
915 10646", RFC 3629, November 2003.
916
917 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
918 Registration", RFC 3848, July 2004.
919
920 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
921 Specifications: ABNF", STD 68, RFC 5234, January 2008.
922
923 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
924 Mail System Status Codes", RFC 5248, June 2008.
925
926 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
927 October 2008.
928
929 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
930 October 2008.
931
932 [RFC5890] Klensin, J., "Internationalizing Domain Names in
933 Applications (IDNA definitions)", RFC 5890, June 2010.
934
935 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
936 Service Extension for 8-bit MIME Transport", STD 71,
937 RFC 6152, March 2011.
938
939 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
940 STD 72, RFC 6409, November 2011.
941
942 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
943 Internationalized Email", RFC 6530, February 2012.
944
945 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
946 Email Headers", RFC 6532, February 2012.
947
948 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed.,
949 "Internationalized Delivery Status and Disposition
950 Notifications", RFC RFC6533, February 2012.
951
952
953
954Yao & Mao Standards Track [Page 17]
955
956RFC 6531 SMTP Extension for SMTPUTF8 February 2012
957
958
9597.2. Informative References
960
961 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
962 October 1996.
963
964 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
965 Extensions (MIME) Part One: Format of Internet Message
966 Bodies", RFC 2045, November 1996.
967
968 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
969 of Large and Binary MIME Messages", RFC 3030,
970 December 2000.
971
972 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
973 Transport Layer Security", RFC 3207, February 2002.
974
975 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
976 for Authentication", RFC 4954, July 2007.
977
978 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
979 Email Addresses", RFC 5336, September 2008.
980
981 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
982 July 2009.
983
984Authors' Addresses
985
986 Jiankang YAO
987 CNNIC
988 No.4 South 4th Street, Zhongguancun
989 Beijing
990 China
991
992 Phone: +86 10 58813007
993 EMail: yaojk@cnnic.cn
994
995
996 Wei MAO
997 CNNIC
998 No.4 South 4th Street, Zhongguancun
999 Beijing
1000 China
1001
1002 Phone: +86 10 58812230
1003 EMail: maowei_ietf@cnnic.cn
1004
1005
1006
1007
1008
1009
1010Yao & Mao Standards Track [Page 18]
1011
1012