Network Working Group J. Yao Internet-Draft S. Shen Intended status: Standards Track CNNIC Expires: September 6, 2012 March 5, 2012 SMTPUTF8 Capability Indicator draft-yao-eai-dns-00.txt Abstract Key RFCs for internationalized email addresses specify the basic protocols for using them. The SMTP client can only know the SMTP server's ability by EHLO command. In order to help the internationalized email address delivery, this document suggests to add the new DNS RR type for internationalized email protocols. Through this RR type, the SMTP client can know whether the destination SMTP server can support the SMTPUTF8 ability before sending the EHLO command to the server. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Yao & Shen Expires September 6, 2012 [Page 1] Internet-Draft EAI DNS March 2012 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The SMTPUTF8 Resource Record . . . . . . . . . . . . . . . . . 3 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. The usage of SMTPUTF8 RR . . . . . . . . . . . . . . . . . 4 2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. draft-yao-eai-dns: Version 00 . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Yao & Shen Expires September 6, 2012 [Page 2] Internet-Draft EAI DNS March 2012 1. Introduction The IETF key RFCs [RFC6530] [RFC6531] [RFC6532] [RFC6533] provide the basis of internationalized email addresses. internationalized email Protocols are used to exchange the message between at least two SMTPUTF8-aware SMTP servers. If only one SMTP server supports the internationalized email protocols, then internationalized email SHOULD not be used. It is not possible to support internationalized email protocol within one night. It is clear that one internationalized email user sends the message to one internationalized email user or one ASCII user. The situation is a little complex when one internationalized email user sends the multi- users who the Message Submission Agent (MSA)[RFC6409] cannot know whether the destination SMTP server can support the SMTPUTF8 ability before sending the EHLO command to the server. On the other hand, we cannot judge the SMTPUTF8 ability just according to the email address itself. Even if an destination email address is all-ASCII, it still has the possibility that the destination server is SMTPUTF8-aware. If an internationalized email user sends the message to both internationalized email users and ASCII users, a MSA can deal it with its own way based on [RFC6531]. The MSA may choose the following strategy: if all recipients are internationalized email users, it will use SMTPUTF8 ability to send the message; if one of the recipients is the ASCII user, it may choose the rejection of the message or other ways. For example, if an internationalized message is sent to 10 users one of which is an ASCII user, the MSA may have to say EHLO 10 times before deciding to reject the message. This procedure of judging whether the SMTP server is SMTPUTF8-aware is time-consuming. In order to help the internationalized email address delivery and save time, this document suggests to add the new DNS RR type for internationalized email protocols. Through this RR type, the SMTP client can know whether the destination SMTP server can support the SMTPUTF8 ability before sending the EHLO command to the server. 1.1. Terminology All the specialized terms used in this specification are defined in the framework document [RFC6530], the internationalized email SMTP extension document [RFC6531], the internationalized email header document [RFC6532] and the base Internet email specifications [RFC5321] [RFC5322], and the basic DNS protocols [RFC1035]. 2. The SMTPUTF8 Resource Record Yao & Shen Expires September 6, 2012 [Page 3] Internet-Draft EAI DNS March 2012 2.1. Format The SMTPUTF8 RR has mnemonic SMTPUTF8 and type code xx (decimal). It is not class-sensitive. Its RDATA is comprised of a single field, . The field MUST be present. The value of is that domain names [RFC1035] separated by semicolon or the value is "all" or "no". If the value is the domain names, it means that the hosts represented by the domain names are SMTPUTF8-aware. If the value is "all", it means that all the hosts pointed by the owner domain name MX records are SMTPUTF8-aware. If the value is "no", it means that all the hosts pointed by the owner domain name MX records are not SMTPUTF8-aware. The wildcards in the SMTPUTF8 RR SHOULD NOT be used. SMTPUTF8 The SMTPUTF8 RR indicates that whether the domain represented by the owner of the SMTPUTF8 RR is SMTPUTF8-aware or not. 2.2. The usage of SMTPUTF8 RR All SMTPUTF8-aware SMTP servers should be configured with the SMTPUTF8 RR. The SMTPUTF8-aware SMTP client or MSA should check the SMTPUTF8 type before sending the internationalized message to the multi-users. If there is no SMTPUTF8 RR configured for the specific domain, the SMTP client should regard that domain as SMTPUTF8-unware. If the SMTPUTF8 RR is configured for the specific domain, the SMTP client should act based on the value of SMTPUTF8 RR. 2.3. Discussion [[anchor4: This topic is for WG discussion. If a new DNS type is not suggested, a TXT record with the special target value may be used. (The mechanism follows the dkim example.)]] 3. IANA Considerations The type code xx should be assigned by IANA. 4. Security Considerations See the extended security considerations discussion in the framework document [RFC6530]. The administrators of email systems should configure this new DNS RR type while configuring their internationalized email service. The Yao & Shen Expires September 6, 2012 [Page 4] Internet-Draft EAI DNS March 2012 SMTP client can know the server's ability before saying EHLO. There may have some mis-configurations. For example, althoug the SMTPUTF8 RR is not configured, but the server indeed supports the SMTPUTF8. Under this situation, the client may refuse to send the internationalized message. 5. Acknowledgements Many thanks to coremail colleagues' helpful discussions. 6. Change History [[anchor8: RFC Editor: Please remove this section.]] 6.1. draft-yao-eai-dns: Version 00 o dns lookup for eai 7. References 7.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012. [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, February 2012. [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012. Yao & Shen Expires September 6, 2012 [Page 5] Internet-Draft EAI DNS March 2012 [RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012. 7.2. Informative References [DeploymentTests] YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test and Evaulation for EAI deployment", draft-yao-eai-tests-00.txt (work in progress), August 2009. Authors' Addresses Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813007 Email: yaojk@cnnic.cn Shuo SHEN CNNIC No.4 South 4th Street, Zhongguancun Beijing Email: shenshuo@cnnic.cn Yao & Shen Expires September 6, 2012 [Page 6]