RFC 6857 Proposed Standard Internationalization

Post-Delivery Message Downgrading for Internationalized Email Messages

The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
March 2013
Authors
K. Fujiwara
Read it
rfc-editor.org · errata · DOI

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 0 must, 5 should, 0 may.

3.2.8 Other Header Fields

  • SHOULDIf the software understands the header field's structure and a downgrading algorithm other than Unstructured is applicable, that software SHOULD use that algorithm; Unstructured downgrading is used when there is no other option.

5 Security Considerations

  • SHOULD NOTThe downgrade mechanism SHOULD NOT remove signatures even if the signatures will fail validation after downgrading.
  • SHOULDAs much of the information as possible from the original message SHOULD be preserved.

6 Implementation Note: Encoded-Word Encoding

  • SHOULDWhile RFC 5322 states that implementations SHOULD limit lines to 78 characters or less, implementations MAY choose to allow overly long encoded words to work around faulty implementations of encoded-words.
  • SHOULDImplementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters.

Every current email RFC