[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,
   <target>.  The <target> field MUST be present.  The value of <target>
   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.

     <owner> <ttl> <class> SMTPUTF8 <target>

   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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/