Internet DRAFT - draft-yao-eai-dns
draft-yao-eai-dns
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]
