RFC 6858

RFC 6858: Simplified POP and IMAP Downgrading for Internationalized Email 💌

okay bestie, let's get the basics out of the way first 🎀 This one is by A. Gulbrandsen (Arnt Gulbrandsen), dated March 2013. It's a Standards Track doc, so it's an actual official IETF spec and not just an idea someone floated 💅 It Updates 3501 (that's the base IMAP spec, [RFC3501]) and doesn't obsolete anything. The ISSN is 2070-1721, if you're collecting those 🦋

Abstract

this doc describes how IMAP and POP servers can show internationalized messages to regular, old-school clients 🌸 The method is simple to build and easy to implement, but the results are only rudimentary. it's giving "good enough" and honestly that's the point ✨

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.

1. Overview 🌈

a regular IMAP or POP client might open a mailbox full of internationalized messages, or even try to read them 👀 This happens when a user has both internationalized and conventional Mail User Agents (MUAs), which is super common vibes.

some stuff just can't be done by conventional clients 😭 The biggest problem is that an internationalized message usually has at least one internationalized address in it, so address-based operations are rarely possible. That covers displaying the addresses, replying to messages, and handling most kinds of address-based signature or security stuff 💀

BUT the sender's name, the subject, the body text, and attachments can all be displayed just fine ✨ So a helpful IMAP or POP server may prefer to show as much of the message as it can, instead of hiding the whole thing 🫶

this document is about how to present these messages to the client. It goes for simplicity over fidelity 💖 The companion doc [RFC6857] has a high-fidelity downgrade algorithm, but implementing that is likely more work than just doing proper UTF-8 support for POP [RFC6856] and/or IMAP [RFC6855]. no cap, the simple route wins here 🍓

The server is assumed to be internationalized on the inside, and to store internationalized messages natively 🧚 When it needs to show one of those to a conventional client, it builds a conventional message that has most of the info and presents that. This is called the "surrogate message" 🎀

This specification modifies the base IMAP specification [RFC3501] in two ways. It relaxes a requirement that sizes be exact, and it adds a reporting requirement. More on that in Section 3 below 💅

2. Information Preserved and Lost 🦋

the surrogate message is meant to get the most important info to the user 💜 If info gets lost, the user should think of the message as incomplete, not as modified. That's a big distinction, bestie.

the surrogate message is also NOT meant to give the client software any info that would let it do special handling. Client authors who want to handle internationalized messages are encouraged to add POP [RFC6856] and/or IMAP [RFC6855] support for UTF-8 🌸

in the examples, UPPERCASE letters stand for non-ASCII characters. So example.com is a plain domain, and EXAMPLE.com is a non-ASCII domain in the .com top-level domain 🔥

2.1. Email Addresses 💌

each internationalized email address in the header fields listed below gets replaced with an invalid email address. Its display-name tells the user what happened 🙈

the display-name format is explicitly unspecified. Anything that tells the user what happened is good ✨ Anything that makes an email address that could belong to someone else is bad 💀 big no.

say we have an internationalized address like this:

Fred Foo <fred@EXAMPLE.com>

an implementation may choose to render it as any of these:

"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]. So the first two examples are syntactically valid, but they will never belong to anyone 🧚 Also, the display-name often needs encoding (see the Message Header Extensions document [RFC2047]).

the affected header fields are these:

Bcc:
Cc:
From:
Reply-To:
Resent-Bcc:
Resent-Cc:
Resent-From:
Resent-Sender:
Resent-To:
Return-Path:
Sender:
To:

any addresses in other header fields, like Received:, are NOT treated as addresses by this spec. they're just vibes 🌈

2.2. MIME Parameters 🎀

any MIME parameter [RFC2045] (whether it's in the message header or a body part header) that can't be shown to the client exactly as it appears in the incoming message gets silently excised 🫥 Yep, quietly removed, no announcement.

say we have a field like this:

Content-Disposition: attachment; filename=FOO

it gets presented as:

Content-Disposition: attachment

RIP the filename, but the attachment is still there 😭🫶

2.3. Subject Field 🌸

if the Subject field can't be shown to the client exactly as it appears in the incoming message, the server presents an encoded version instead. That encoding is specified in RFC 2047 ✨

2.4. Remaining Header Fields 💅

any header field that still can't be shown to the client, even after the modifications from Sections 2.1-2.3, gets silently excised 💀 gone, bestie.

3. IMAP-Specific Details 🦋

IMAP lets clients grab the message size without downloading the message, using RFC822.SIZE, BODY.SIZE[] and so on. The IMAP spec [RFC3501] says the returned size has to be exact 🤓

this spec relaxes that. When a conventional client asks for size info, the IMAP server is allowed to return the size of the internationalized message, even though the surrogate message has a different size 🧚

when an IMAP server downgrades stuff while generating FETCH responses, it reports which messages got synthesized. It does that with a response code and an attached UID (Unique Identifier) set 🔥 This can be super helpful for humans debugging the server and/or client 🙈

here's what that looks like:

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 💜

BUT, note that DOWNGRADED doesn't necessarily list ALL the internationalized messages in the mailbox 👀 In the example above, we know that UID 65 doesn't have internationalized addresses in its "From:", "To:", and "Cc:" fields. It might still have an internationalized "Subject:", though, for example 🌈

4. POP-Specific Details 🍓

the number of lines given in the TOP command [RFC1939] refers to the surrogate message 🎀 The message size reported by, for example, LIST might refer to either the internationalized message or the surrogate message. Either one is possible, so don't assume 😭

5. Security Considerations 💀

this section is SERIOUS, bestie. Read it carefully.

if the internationalized message uses any sort of signature that covers header fields, the signature of the surrogate message almost certainly is invalid, and it may be invalid in other cases too 😭 This is a necessary limitation of showing internationalized messages in legacy clients, since those clients don't support internationalized header fields. These cases are discussed in more detail in the POP or IMAP Downgrade document [RFC6857]. Even though they're invalid, these signatures should not be removed from the surrogate message, so as much of the original info as possible is preserved 🫶

if any excised information is significant, then that info doesn't reach the recipient 🥺 Notably, the "Message-Id:", "In-Reference-To:", and "References:" fields may get excised. That could cause a lack of context when the recipient reads the message.

some POP or IMAP clients, like Fetchmail, download messages and then delete the versions on the server 💀 This can 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, like the stock Android client 🙈 When a client like that is internationalized, care must be taken so that it doesn't use an old surrogate message from its cache instead of retrieving the real message from the server. Main character energy is making sure the client grabs the real one 👑

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.
• [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 🫶

big thank-yous to Claudio Allocchio, Ned Freed, Kazunori Fujiwara, Ted Hardie, John Klensin, Barry Leiba, John Levine, Alexey Melnikov, Chris Newman, and Joseph Yee 💖 This spec was inspired by Rule 12 of "The Twelve Networking Truths" [RFC1925], which is an iconic rule, honestly 👑

Author's Address 💌

Arnt Gulbrandsen
Schweppermannstr. 8
D-81671 Muenchen
Germany

Fax: +49 89 4502 9758
EMail: arnt@gulbrandsen.priv.no