RFC 1137

Mapping Between Full RFC 822 and RFC 822 with Restricted Encoding 💖

okay bestie, this is RFC 1137 🎀 by Steve Kille from University College London, dated December 1989 🦋. It's from the Network Working Group, and it updates RFC 976 (the UUCP mail interchange one 👀). Kille is the only author listed, so all the credit goes to him 👑.

---

Status of this Memo ✨

okay so this RFC suggests an electronic mail protocol mapping for the Internet community and the UK Academic Community, and it's literally asking for discussion and suggestions to make it better 🫶. This memo does not specify an Internet standard. Distribution of this memo is unlimited 🌈.

This document describes a set of address mappings that let systems running RFC 822 protocols in a general way talk to environments where RFC 822 messages are transferred with a restricted character set for addresses. UUCP transfer of RFC 822 messages is the big example here [Crocker82a, Horton86a] 🍓.

Specification 🔥

this document specifies a mapping between two protocols. The specification should be used when this mapping is done on the Internet or in the UK Academic Community. It may be changed based on implementation experience, but no big changes are expected 🧚.

1. Introduction 🌸

some mail networks that use RFC 822 can't support the full character set that every part of RFC 822 needs 😭. This document describes a symmetrical mapping between full RFC 822 addressing and a form for use on those networks. Addresses inside those networks won't use full RFC 822 addressing, so any address encoded under this standard will always be a remote address 💅. This document grows out of a mapping first specified in RFC 987 [Kille86a], which had a more limited scope. Two terms are defined now:

Full RFC 822

This means full support for transfer to and from any legal RFC 822 address. In particular, the quoted-string form of local-part must be supported (e.g., <"Joe Soap"@foo.bar>) ✨.

Restricted RFC 822

This means a subset of RFC 822 addressing. The quoted-string form of local-part need not be supported. Standard UUCP mail transfer is in this category. Restricted RFC 822 is undesirable, but in practice it exists in lots of places 🙈.

When a message goes from full RFC 822 to restricted RFC 822, and address forms from full RFC 822 are involved, message loss may happen (for example, it might not be possible to send an error message back) 💀. This RFC describes a quoting mechanism that may be used to map between full RFC 822 and restricted RFC 822, to help fix this problem 🦋.

2. Encoding 🎀

The RFC 822 EBNF meta notation is used. Any EBNF definitions taken from RFC 822 are prefixed by the string "822." 💜.

The following EBNF is specified:

   atom-encoded    = *( a-char / a-encoded-char )
   a-char          = <any CHAR except specials (other than "@"
                           and "."), SPACE,
                           CTL, "_", and "#">
   a-encoded-char  = "_"                   ; (space)
                   / "#u#"                 ; (_)
                   / "#l#"                 ; <(>
                   / "#r#"                 ; <)>
                   / "#m#"                 ; (,)
                   / "#c#"                 ; (:)
                   / "#b#"                 ; (\)
                   / "#h#"                 ; (#)
                   / "#e#"                 ; (=)
                   / "#s#"                 ; (/)
                   / "#" 3DIGIT "#"

okay the 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and it gets read in decimal as the matching ASCII character 🔢. The special abbreviations (instead of decimal encoding) were picked because of how this mapping gets used most of the time 🫶. There are special encodings for each PrintableString character that isn't in EBNF.a-char, except ".". Space gets a single character encoding because it's expected to show up a lot, and backslash is the RFC 822 single quote character 🌈.

This mapping transforms between the two forms of 822.word: 822.quoted-string (restricted RFC 822) and 822.atom (restricted RFC 822). To encode (full RFC 822 to restricted RFC 822), first remove any quoting from any 822.quoted-string. Then EBNF.a-char gets used directly, and every other CHAR gets encoded as EBNF.a-encoded-char ✨.

To decode (restricted RFC 822 to full RFC 822): if the address can be parsed as EBNF.encoded-atom, reverse the previous mapping. If it can't be parsed that way, map the characters directly 🧚.

3. Application 💖

This mapping should be used for all addresses, at the MTS or Header level. It is applied to the 822.local-part of the addresses. For example:

   Full RFC 822                       Restricted RFC 822

   Steve.Kille@cs.ucl.ac.uk     <->   Steve.Kille@cs.ucl.ac.uk
   "Steve Kille"@cs.ucl.ac.uk   <->   Steve_Kille@cs.ucl.ac.uk
   "argle#~"@blargle            <->   argle#h##126#@blargle

References 📚

• [Crocker82a] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, August 1982.
• [Horton86a] Horton, M., "UUCP Mail Interchange Format Standard", RFC 976, February 1986.
• [Kille86a] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic Community Report (MG.19), RFC 987, June 1986.

Security Considerations 💀

plot twist: security issues are not discussed in this memo 🙈.

Author's Address 🦋

   Steve Kille
   University College London
   Gower Street
   WC1E 6BT
   England

   Phone: +44-1-380-7294

   EMail: S.Kille@Cs.Ucl.AC.UK