Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group S. Kille Request for Comments: 1137 University College London Updates: RFC 976 December 1989

           Mapping Between Full RFC 822 and RFC 822 with
                        Restricted Encoding

Status of this Memo

 This RFC suggests an electronic mail protocol mapping for the
 Internet community and UK Academic Community, and requests discussion
 and suggestions for improvements.  This memo does not specify an
 Internet standard.  Distribution of this memo is unlimited.
 This document describes a set of address mappings which will enable
 interworking between systems operating RFC 822 protocols in a general
 manner, and those environments where transfer of RFC 822 messages
 restricts the character set which can be used in addresses.  UUCP
 transfer of RFC 822 messages is an important case of this
 [Crocker82a, Horton86a].


 This document specifies a mapping between two protocols.  This
 specification should be used when this mapping is performed on the
 Internet or in the UK Academic Community. This specification may be
 modified in the light of implementation experience, but no
 substantial changes are expected.

1. Introduction

 Some mail networks which use RFC 822 cannot support the full
 character set required by all aspects of RFC 822.  This document
 describes a symmetrical mapping between full RFC 822 addressing, and
 a form for use on these networks.  Any addresses within the networks
 will not use the full RFC 822 addressing, and so any addresses
 encoded according to this standard will always represent remote
 addresses.  This document derives from a mapping originally specified
 in RFC 987 [Kille86a], where the domain of application was more
 restricted.  Two terms are now defined:
 Full RFC 822
    This implies 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">).

Kille [Page 1] RFC 1137 E-Mail Address and Quoted Strings December 1989

 Restricted RFC 822
    This implies a subset of RFC 822 addressing.  The quoted-string
    form of local-part need not be supported.  Standard UUCP mail
    transfer falls into this category.  Restricted RFC 822 is
    undesirable, but in practice it exists in many places.
    When a message is transferred from full RFC 822 to restricted RFC
    822, and address forms used in full RFC 822 are involved, message
    loss may occur (e.g., it may not be possible to return an error
    message).  This RFC describes a quoting mechanism which may be
    used to map between full RFC 822 and restricted RFC 822, in order
    to alleviate 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 "#"
 The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and is
 interpreted in decimal as the corresponding ASCII character.  The
 choice of special abbreviations (as opposed to decimal encoding)
 provided is based on the manner in which this mapping is most
 frequently used.  There are special encodings for each of the
 PrintableString characters not in EBNF.a-char, except ".".  Space is
 given a single character encoding, due to its (expected) frequency of
 use, and backslash as the RFC 822 single quote character.
 This mapping is used to transform between the two forms of 822.word:
 822.quoted-string (restricted RFC 822) and 822.atom (restricted RFC

Kille [Page 2] RFC 1137 E-Mail Address and Quoted Strings December 1989

 822).  To encode (full RFC 822 -> restricted RFC 822), first remove
 any quoting from any 822.quoted-string.  Then, all EBNF.a-char are
 used directly and all other CHAR are encoded as EBNF.a-encoded-char.
 To decode (restricted RFC 822 -> full RFC 822): if the address can be
 parsed as EBNF.encoded-atom reverse the previous mapping.  If it
 cannot be so parsed, 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
    Full RFC 822                       Restricted RFC 822     <->
    "Steve Kille"   <->
    "argle#~"@blargle            <->   argle#h##126#@blargle


 [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

 Security issues are not discussed in this memo.

Author's Address

 Steve Kille
 University College London
 Gower Street
 Phone: +44-1-380-7294
 EMail: S.Kille@Cs.Ucl.AC.UK

Kille [Page 3]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1137.txt · Last modified: 1992/09/10 21:32 (external edit)