draft-ietf-eai-rfc5721bis-07.txt   draft-ietf-eai-rfc5721bis-08.txt 
Network Working Group R. Gellens Network Working Group R. Gellens
Internet-Draft QUALCOMM Incorporated Internet-Draft QUALCOMM Incorporated
Obsoletes: 5721 (if approved) C. Newman Obsoletes: 5721 (if approved) C. Newman
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: February 1, 2013 J. Yao Expires: April 25, 2013 J. Yao
CNNIC CNNIC
K. Fujiwara K. Fujiwara
JPRS JPRS
July 31, 2012 October 22, 2012
POP3 Support for UTF-8 POP3 Support for UTF-8
draft-ietf-eai-rfc5721bis-07.txt draft-ietf-eai-rfc5721bis-08.txt
Abstract Abstract
This specification extends the Post Office Protocol version 3 (POP3) This specification extends the Post Office Protocol version 3 (POP3)
to support UTF-8 encoded international string in user names, to support UTF-8 encoded international string in user names,
passwords, mail addresses, message headers, and protocol-level passwords, mail addresses, message headers, and protocol-level
textual strings. textual strings.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 1, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10 8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10
8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10 8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10
8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11 8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11
8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11 8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11
8.5. draft-ietf-eai-rfc5721bis: Version 04 . . . . . . . . . . 11 8.5. draft-ietf-eai-rfc5721bis: Version 04 . . . . . . . . . . 11
8.6. draft-ietf-eai-rfc5721bis: Version 05 . . . . . . . . . . 11 8.6. draft-ietf-eai-rfc5721bis: Version 05 . . . . . . . . . . 11
8.7. draft-ietf-eai-rfc5721bis: Version 06 . . . . . . . . . . 11 8.7. draft-ietf-eai-rfc5721bis: Version 06 . . . . . . . . . . 11
8.8. draft-ietf-eai-rfc5721bis: Version 07 . . . . . . . . . . 11 8.8. draft-ietf-eai-rfc5721bis: Version 07 . . . . . . . . . . 11
8.9. draft-ietf-eai-rfc5721bis: Version 08 . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document forms part of the Email Address Internationalization This document forms part of the Email Address Internationalization
protocols described in the Email Address Internationalization protocols described in the Email Address Internationalization
skipping to change at page 4, line 49 skipping to change at page 4, line 49
mode. The UTF-8 mode means that, all messages transmitted between mode. The UTF-8 mode means that, all messages transmitted between
servers and clients are UTF-8 strings, and both servers and clients servers and clients are UTF-8 strings, and both servers and clients
can send and accept UTF-8 string. can send and accept UTF-8 string.
2.1. The UTF8 Command 2.1. The UTF8 Command
The UTF8 command enables UTF-8 mode. The UTF8 command has no The UTF8 command enables UTF-8 mode. The UTF8 command has no
parameters. parameters.
UTF-8 mode has no effect on messages in an ASCII-only maildrop. UTF-8 mode has no effect on messages in an ASCII-only maildrop.
Messages in native UTF-8 maildrops can be ASCII or UTF-8 using Messages in native UTF-8 maildrops can be encoded either in UTF-8
internationalized headers [RFC6532] and/or 8bit content-transfer- using internationalized headers [RFC6532] and/or 8bit content-
encoding, as defined in MIME Section 2.8 [RFC2045]. The character transfer-encoding (see MIME Section 2.8 [RFC2045]), or in ASCII. The
encoding format of maildrops may not be UTF-8 or ASCII. In UTF-8 message at maildrops can be encoded in ASCII, UTF-8, or something
mode, if the character encoding format of maildrops is UTF-8 or else. In UTF-8 mode, if the character encoding format of maildrops
ASCII, the messages are sent to the client as-is; if the character is UTF-8 or ASCII, the messages are sent to the client as-is; if the
encoding format of maildrops is format other than UTF-8 or ASCII, the character encoding format of maildrops is format other than UTF-8 or
messages' encoding format SHOULD be converted to be UTF-8 before they ASCII, the messages' encoding format SHOULD be converted to be UTF-8
are sent to the client. When not in UTF-8 mode, non-ASCII string before they are sent to the client. When UTF-8 mode has not been
messages including UTF-8 string messages in the maildrop MUST NOT be enabled, non-ASCII strings MUST NOT be sent to the client as-is. If
sent to the client as-is. If a client requests a UTF-8 message when a client requests a UTF-8 message when UTF-8 mode is not enabled, the
not in UTF-8 mode, the server MUST either create the message content server MUST either send the client a surrogate message that complies
variant (discussed in Section 7 of [I-D.ietf-eai-5738bis]) it sends with unextended POP and Internet Mail Format without UTF-8 mode
to the client to comply with unextended POP and Internet Mail Format support, or fail the request with a -ERR response. See
without UTF-8 mode support, or fail the request with a -ERR response [I-D.ietf-eai-5738bis], Section 7, for information about creating a
containing the UTF-8 response code (see section 5). The UTF8 command surrogate message, and for a discussion of potential issues. Section
MAY fail. 5 of this document discusses UTF8 response codes. The server MAY
respond to the UTF8 command with an -ERR response.
Note that even in UTF-8 mode, MIME binary content-transfer-encoding Note that even in UTF-8 mode, MIME binary content-transfer-encoding
as defined in MIME Section 6.2 [RFC2045] is still not permitted. as defined in MIME Section 6.2 [RFC2045] is still not permitted.
MIME 8bit content-transfer-encoding (8BITMIME) [RFC6152] is obviously
allowed.
The octet count (size) of a message reported in a response to the The octet count (size) of a message reported in a response to the
LIST command SHOULD match the actual number of octets sent in a RETR LIST command SHOULD match the actual number of octets sent in a RETR
response (not counting byte-stuffing). Sizes reported elsewhere, response (not counting byte-stuffing). Sizes reported elsewhere,
such as in STAT responses and non-standardized, free-form text in such as in STAT responses and non-standardized, free-form text in
positive status indicators (following "+OK") need not be accurate, positive status indicators (following "+OK") need not be accurate,
but it is preferable if they were. but it is preferable if they were.
Normal operation for maildrops that natively support non-ASCII Normal operation for maildrops that natively support non-ASCII
characters will be for both servers and clients to support the characters will be for both servers and clients to support the
skipping to change at page 10, line 30 skipping to change at page 10, line 30
The "LANG *" command might reveal the existence and preferred The "LANG *" command might reveal the existence and preferred
language of a user to an active attacker probing the system if the language of a user to an active attacker probing the system if the
active language changes in response to the USER, PASS, or APOP active language changes in response to the USER, PASS, or APOP
commands prior to validating the user's credentials. Servers are commands prior to validating the user's credentials. Servers are
strongly advised to implement a configuration to prevent this strongly advised to implement a configuration to prevent this
exposure. exposure.
It is possible for a man-in-the-middle attacker to insert a LANG It is possible for a man-in-the-middle attacker to insert a LANG
command in the command stream, thus making protocol-level diagnostic command in the command stream, thus making protocol-level diagnostic
responses unintelligible to the user. A mechanism to protect the responses unintelligible to the user. A mechanism to protect the
integrity of the session, such as Transport Layer Security (TLS) integrity of the session can be used to defeat such attacks. For
[RFC2595] can be used to defeat such attacks. example, a client can issue the STLS command [RFC2595] before issuing
the LANG command.
As with other internationalization upgrades, modifications to server As with other internationalization upgrades, modifications to server
authentication code (in this case, to support non-ASCII strings) authentication code (in this case, to support non-ASCII strings)
needs to be done with care to avoid introducing vulnerabilities (for needs to be done with care to avoid introducing vulnerabilities (for
example, in string parsing or matching). This is particularly example, in string parsing or matching). This is particularly
important if the native databases or mailstore of the operating important if the native databases or mailstore of the operating
system use some character set or encoding other than Unicode in system use some character set or encoding other than Unicode in
UTF-8. UTF-8.
8. Change History 8. Change History
skipping to change at page 11, line 36 skipping to change at page 11, line 36
8.7. draft-ietf-eai-rfc5721bis: Version 06 8.7. draft-ietf-eai-rfc5721bis: Version 06
improve the texts, updated section 3.2 to provide for SASL successor improve the texts, updated section 3.2 to provide for SASL successor
specs. specs.
8.8. draft-ietf-eai-rfc5721bis: Version 07 8.8. draft-ietf-eai-rfc5721bis: Version 07
updated according to John's comments updated according to John's comments
8.9. draft-ietf-eai-rfc5721bis: Version 08
improve the texts
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. Shen, "IMAP [I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. Shen, "IMAP
Support for UTF-8", draft-ietf-eai-5738bis-03 Support for UTF-8", draft-ietf-eai-5738bis-03
(work in progress), December 2011. (work in progress), December 2011.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol [RFC1939] Myers, J. and M. Rose, "Post Office Protocol
- Version 3", STD 53, RFC 1939, May 1996. - Version 3", STD 53, RFC 1939, May 1996.
skipping to change at page 12, line 43 skipping to change at page 12, line 48
for Network Interchange", RFC 5198, for Network Interchange", RFC 5198,
March 2008. March 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", [RFC5322] Resnick, P., Ed., "Internet Message Format",
RFC 5322, October 2008. RFC 5322, October 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for [RFC5646] Phillips, A. and M. Davis, "Tags for
Identifying Languages", BCP 47, RFC 5646, Identifying Languages", BCP 47, RFC 5646,
September 2009. September 2009.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D.
Crocker, "SMTP Service Extension for 8-bit
MIME Transport", STD 71, RFC 6152,
March 2011.
[RFC6530] Klensin, J. and Y. Ko, "Overview and [RFC6530] Klensin, J. and Y. Ko, "Overview and
Framework for Internationalized Email", Framework for Internationalized Email",
RFC 6530, February 2012. RFC 6530, February 2012.
[RFC6532] Yang, A., Steele, S., and N. Freed, [RFC6532] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", RFC 6532, "Internationalized Email Headers", RFC 6532,
February 2012. February 2012.
9.2. Informative References 9.2. Informative References
 End of changes. 10 change blocks. 
23 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/