summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6858.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6858.txt')
-rw-r--r--doc/rfc/rfc6858.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6858.txt b/doc/rfc/rfc6858.txt
new file mode 100644
index 0000000..9ec4795
--- /dev/null
+++ b/doc/rfc/rfc6858.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Gulbrandsen
+Request for Comments: 6858 March 2013
+Updates: 3501
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Simplified POP and IMAP Downgrading for Internationalized Email
+
+Abstract
+
+ This document specifies a method for IMAP and POP servers to serve
+ internationalized messages to conventional clients. The
+ specification is simple, easy to implement, and provides only
+ rudimentary results.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6858.
+
+Copyright Notice
+
+ Copyright (c) 2013 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
+ 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.
+
+
+
+
+
+
+
+Gulbrandsen Standards Track [Page 1]
+
+RFC 6858 POP and IMAP for Internationalized Email March 2013
+
+
+1. Overview
+
+ A conventional IMAP or POP client may open a mailbox containing
+ internationalized messages or may even attempt to read
+ internationalized messages, for instance, when a user has both
+ internationalized and conventional Mail User Agents (MUAs).
+
+ Some operations cannot be performed by conventional clients. Most
+ importantly, an internationalized message usually contains at least
+ one internationalized address, so address-based operations are rarely
+ possible. This includes displaying the addresses, replying to
+ messages, and the processing of most types of address-based signature
+ or security.
+
+ However, the sender's name, message subject, body of text, and
+ attachments can easily be displayed, so a helpful IMAP or POP server
+ may prefer to display as much of the message as possible, rather than
+ hide the message entirely.
+
+ This document specifies a way to present such messages to the client.
+ It values simplicity of implementation over fidelity of
+ representation, since implementing a high-fidelity downgrade
+ algorithm such as the one specified in a companion document [RFC6857]
+ is likely more work than implementing proper UTF-8 support for POP
+ [RFC6856] and/or IMAP [RFC6855].
+
+ The server is assumed to be internationalized internally and to store
+ messages that are internationalized messages natively. When it needs
+ to present an internationalized message to a conventional client, the
+ server synthesizes a conventional message containing most of the
+ information and presents the "surrogate message".
+
+ This specification modifies the base IMAP specification [RFC3501] by
+ relaxing a requirement that sizes be exact and adding a reporting
+ requirement as discussed in Section 3 below.
+
+2. Information Preserved and Lost
+
+ The surrogate message is intended to convey the most important
+ information to the user. Where information is lost, the user should
+ consider the message incomplete rather than modified.
+
+ The surrogate message is not intended to convey any information to
+ the client software that would require or enable it to apply special
+ handling to the message. Client authors who wish to handle
+ internationalized messages are encouraged to implement POP [RFC6856]
+ and/or IMAP [RFC6855] support for UTF-8.
+
+
+
+
+Gulbrandsen Standards Track [Page 2]
+
+RFC 6858 POP and IMAP for Internationalized Email March 2013
+
+
+ Uppercase letters in examples represent non-ASCII characters.
+ example.com is a plain domain; EXAMPLE.com represents a non-ASCII
+ domain in the .com top-level domain.
+
+2.1. Email Addresses
+
+ Each internationalized email address in the header fields listed
+ below is replaced with an invalid email address whose display-name
+ tells the user what happened.
+
+ The format of the display-name is explicitly unspecified. Anything
+ that tells the user what happened is good. Anything that produces an
+ email address that might belong to someone else is bad.
+
+ Given an internationalized address "Fred Foo <fred@EXAMPLE.com>", an
+ implementation may choose to render it as one of these examples:
+
+ "fred@EXAMPLE.com" <invalid@internationalized-address.invalid>
+ Fred Foo <invalid@internationalized.invalid>
+ internationalized-address:;
+ fred:;
+
+ The .invalid top-level domain is reserved as a Top Level DNS Name
+ [RFC2606]; therefore, the first two examples are syntactically valid,
+ but they will never belong to anyone. Note that the display-name
+ often needs encoding (see the Message Header Extensions document
+ [RFC2047]).
+
+ The affected header fields are "Bcc:", "Cc:", "From:", "Reply-To:",
+ "Resent-Bcc:", "Resent-Cc:", "Resent-From:", "Resent-Sender:",
+ "Resent-To:", "Return-Path:", "Sender:", and "To:". Any addresses
+ present in other header fields, such as "Received:", are not regarded
+ as addresses by this specification.
+
+2.2. MIME Parameters
+
+ Any MIME parameter [RFC2045] (whether in the message header or a body
+ part header) that cannot be presented to the client exactly as it
+ appears in the incoming message is silently excised.
+
+ Given a field such as
+
+ Content-Disposition: attachment; filename=FOO
+
+ the field is presented as
+
+ Content-Disposition: attachment
+
+
+
+
+Gulbrandsen Standards Track [Page 3]
+
+RFC 6858 POP and IMAP for Internationalized Email March 2013
+
+
+2.3. Subject Field
+
+ If the Subject field cannot be presented to the client exactly as it
+ appears in the incoming message, the server presents a representation
+ encoded as specified in RFC 2047.
+
+2.4. Remaining Header Fields
+
+ Any header field that cannot be presented to the client, even with
+ the modifications listed in Sections 2.1-2.3, is silently excised.
+
+3. IMAP-Specific Details
+
+ IMAP allows clients to retrieve the message size without downloading
+ the message, using RFC822.SIZE, BODY.SIZE[] and so on. The IMAP
+ specification [RFC3501] requires that the returned size be exact.
+
+ This specification relaxes that requirement. When a conventional
+ client requests size information for a message, the IMAP server is
+ permitted to return size information for the internationalized
+ message, even though the size of the surrogate message differs.
+
+ When an IMAP server performs downgrading as part of generating FETCH
+ responses, it reports which messages were synthesized using a
+ response code and attendant UID (Unique Identifier) set. This can be
+ helpful to humans debugging the server and/or client.
+
+ C: a UID FETCH 1:* BODY.PEEK[HEADER.FIELDS(To From Cc)]
+ S: 1 FETCH (UID 65 [...]
+ S: 2 FETCH (UID 70 [...]
+ S: a OK [DOWNGRADED 70,105,108,109] Done
+
+ The message-set argument to DOWNGRADED contains UIDs.
+
+ Note that DOWNGRADED does not necessarily mention all the
+ internationalized messages in the mailbox. In the example above, we
+ know that UID 65 does not contain internationalized addresses in the
+ "From:", "To:", and "Cc:" fields. It may, for example, contain an
+ internationalized "Subject:".
+
+4. POP-Specific Details
+
+ The number of lines specified in the TOP command [RFC1939] refers to
+ the surrogate message. The message size reported by, for example,
+ LIST may refer to either the internationalized or the surrogate
+ message.
+
+
+
+
+
+Gulbrandsen Standards Track [Page 4]
+
+RFC 6858 POP and IMAP for Internationalized Email March 2013
+
+
+5. Security Considerations
+
+ If the internationalized message uses any sort of signature that
+ covers header fields, the signature of the surrogate message almost
+ certainly is invalid and may be invalid in other cases. This is a
+ necessary limitation of displaying internationalized messages in
+ legacy clients, since those clients do not support internationalized
+ header fields. These cases are discussed in more detail in the POP
+ or IMAP Downgrade document [RFC6857]. Even though invalid, these
+ signatures should not be removed from the surrogate message, to
+ preserve as much of the information as possible from the original
+ message.
+
+ If any excised information is significant, then that information does
+ not arrive at the recipient. Notably, the "Message-Id:",
+ "In-Reference-To:", and "References:" fields may be excised, which
+ might cause a lack of context when the recipient reads the message.
+
+ Some POP or IMAP clients, such as Fetchmail, download messages and
+ delete the versions on the server. This may lead to permanent loss
+ of information when the only remaining version of a message is the
+ surrogate message.
+
+ Other clients cache messages for a very long time, even across client
+ upgrades, such as the stock Android client. When such a client is
+ internationalized, care must be taken so that it does not use an old
+ surrogate message from its cache rather than retrieve the real
+ message from the server.
+
+6. IANA Considerations
+
+ IANA has added DOWNGRADED to the "IMAP Response Codes" registry.
+
+7. References
+
+7.1. Normative References
+
+ [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+ STD 53, RFC 1939, May 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+ Part Three: Message Header Extensions for Non-ASCII Text",
+ RFC 2047, November 1996.
+
+
+
+
+Gulbrandsen Standards Track [Page 5]
+
+RFC 6858 POP and IMAP for Internationalized Email March 2013
+
+
+ [RFC2606] Eastlake, D., 3rd and A. Panitz, "Reserved Top Level DNS
+ Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+ 4rev1", RFC 3501, March 2003.
+
+7.2. Informative References
+
+ [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
+ April 1 1996.
+
+ [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
+ Support for UTF-8", RFC 6855, March 2013.
+
+ [RFC6856] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "Post
+ Office Protocol Version 3 (POP3) Support for UTF-8", RFC
+ 6856, March 2013.
+
+ [RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
+ Internationalized Email Messages", RFC 6857, March 2013.
+
+8. Acknowledgements
+
+ Claudio Allocchio, Ned Freed, Kazunori Fujiwara, Ted Hardie, John
+ Klensin, Barry Leiba, John Levine, Alexey Melnikov, Chris Newman, and
+ Joseph Yee. This specification was inspired by the principle stated
+ in Rule 12 of "The Twelve Networking Truths" [RFC1925].
+
+Author's Address
+
+ Arnt Gulbrandsen
+ Schweppermannstr. 8
+ D-81671 Muenchen
+ Germany
+
+ Fax: +49 89 4502 9758
+ EMail: arnt@gulbrandsen.priv.no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen Standards Track [Page 6]
+