RFC1137 - Mapping between full RFC822 and RFC822 with restricted encoding

领测软件测试网

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

Mapping Between Full RFC822 and RFC822 with
Restricted Encoding

Status of this Memo

This RFCsuggests 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 RFC822 protocols in a general
manner, and those environments where transfer of RFC822 messages
restricts the character set which can be used in addresses. UUCP
transfer of RFC822 messages is an important case of this
[Crocker82a, Horton86a].

Specification

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

Full RFC822

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"@foo.bar>).

Restricted RFC822

This implies a subset of RFC822 addressing. The quoted-string
form of local-part need not be supported. Standard UUCP mail
transfer falls into this category. Restricted RFC822 is
undesirable, but in practice it exists in many places.

When a message is transferred from full RFC822 to restricted RFC
822, and address forms used in full RFC822 are involved, message
loss may occur (e.g., it may not be possible to return an error
message). This RFCdescribes a quoting mechanism which may be
used to map between full RFC822 and restricted RFC822, in order
to alleviate this problem.

2. Encoding

The RFC822 EBNF meta notation is used. Any EBNF definitions taken
from RFC822 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 RFC822 single quote character.

This mapping is used to transform between the two forms of 822.word:
822.quoted-string (restricted RFC822) and 822.atom (restricted RFC

822). To encode (full RFC822 -> restricted RFC822), 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 RFC822 -> full RFC822): 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
example:

Full RFC822 Restricted RFC822

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", RFC822, August 1982.

[Horton86a] Horton, M., "UUCP Mail Interchange Format Standard",
RFC976, February 1986.

[Kille86a] Kille, S., "Mapping Between X.400 and RFC822",
UK Academic Community Report (MG.19), RFC987, June 1986.

Security Considerations

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

文章来源于领测软件测试网 https://www.ltesting.net/