header
Click on the red underlined text to get to the source
... non-ASCII
text in various portions of a RFC 822std11(-> 2822prop) [2] message header, in a manner
which is unlikely to confuse existing message handling software.
...
... outlined here were designed to allow the use of non-ASCII characters
in message headers in a way which is unlikely to be disturbed by the
quirks of existing Internet mail handling programs. In particular,
...
... Internet mail handling programs. In particular,
some mail relaying programs are known to (a) delete some message
header fields while retaining others, (b) rearrange the order of
addresses in To or Cc fields, (c) rearrange the (vertical) order of
...
... addresses in To or Cc fields, (c) rearrange the (vertical) order of
header fields, and/or (d) "wrap" message headers at different places
than those in the original message. In addition, some mail reading
...
... addresses in To or Cc fields, (c) rearrange the (vertical) order of
header fields, and/or (d) "wrap" message headers at different places
than those in the original message. In addition, some mail reading
programs are known to have difficulty correctly parsing message
headers ...
... message headers at different places
than those in the original message. In addition, some mail reading
programs are known to have difficulty correctly parsing message
headers which, while legal according to RFC 822std11(-> 2822prop), make use of
backslash-quoting to "hide" special characters such as "<", ",", or
...
... While it is unfortunate that these programs do not correctly
interpret RFC 822std11(-> 2822prop) headers, to "break" these programs would cause
severe operational problems for the Internet mail system ...
... (known as "encoded-words") are reserved for use as encoded data. The
syntax of encoded-words is such that they are unlikely to
"accidentally" appear as normal text in message headers.
Furthermore, the characters used in encoded-words are restricted to
those which do not have special meanings in the context ...
... A mail composer that implements this specification will provide a
means of inputting non-ASCII text in header fields, but will
translate these fields (or appropriate portions of these fields) into
encoded-words before inserting them into the message header ...
... header fields, but will
translate these fields (or appropriate portions of these fields) into
encoded-words before inserting them into the message header.
...
...
A mail reader that implements this specification will recognize
encoded-words when they appear in certain portions of the message
header. Instead of displaying the encoded-word "as is", it will
reverse the encoding and display the original text in the designated
...
... terminal or nonterminal
symbols from RFC 822std11(-> 2822prop) are used in the grammar for the header
extensions defined here. Among the symbols defined in RFC 822std11(-> 2822prop) and
referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment',
...
... This memo specifies a protocol for the representation of non-ASCII
text in message headers. It specifically DOES NOT define any
translation between "8-bit headers ...
... message headers. It specifically DOES NOT define any
translation between "8-bit headers" and pure ASCII headers, nor is
...
... 1*<Any printable ASCII character other than "?" or SPACE> ; (but see "Use of encoded-words in message headers", section 5) ...
...
While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.
...
...
While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.
...
... through internetwork mail gateways, and to impose a limit on the
amount of lookahead a header parser must employ (while looking for a
final ?= delimiter) before it can decide whether a token is an
...
... ASCII mode is again selected at the end of the 'encoded-word'. (This
rule applies separately to each 'encoded-word', including adjacent
'encoded-word's within a single header field.)
...
... contexts. For example, an 'encoded-word' in a
'phrase' preceding an address in a From header field may not contain
any of the "specials" defined in RFC 822std11(-> 2822prop). Finally, certain other
...
... wide range of printable characters to be used in
non-critical locations in the message header (e.g., Subject), with
fewer characters available for use in other locations.
...
... Use of encoded-words in message headers ...
...
An 'encoded-word' may appear in a message header or body part header
according to the following rules:
...
...
An 'encoded-word' may appear in a message header or body part header
according to the following rules:
...
... 822std11(-> 2822prop))
in any Subject or Comments header field, any extension message
header field, or any MIME body part field for which the field body
...
... in any Subject or Comments header field, any extension message
header field, or any MIME body part field for which the field body
is defined as '*text'. An 'encoded-word' may also appear in any
...
... MIME body part field for which the field body
is defined as '*text'. An 'encoded-word' may also appear in any
user-defined ("X-") message or body part header field.
Ordinary ASCII ...
... Ordinary ASCII text and 'encoded-word's may appear together in the
same header field. However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any adjacent
...
... same header field. However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any adjacent
'encoded-word' or 'text' by 'linear-white-space'.
...
... entity within a 'phrase', for example,
one that precedes an address in a From, To, or Cc header. The ABNF
definition for 'phrase' from RFC 822std11(-> 2822prop) ...
... An 'encoded-word' MUST NOT be used in a Received header field.
...
... Recognition of 'encoded-word's in message headers ...
...
A mail reader must parse the message and body part headers according
to the rules in RFC 822std11(-> 2822prop) to correctly recognize 'encoded-word's.
...
...
(1) Any message or body part header field defined as '*text', or any
user-defined header field, should be parsed as follows: Beginning
...
... (1) Any message or body part header field defined as '*text', or any
user-defined header field, should be parsed as follows: Beginning
at the start of the field-body and immediately following each
...
... ASCII text.
(2) Any header field not defined as '*text' should be parsed
according to the syntax rules for that header field. However,
...
... (2) Any header field not defined as '*text' should be parsed
according to the syntax rules for that header field. However,
any 'word' that appears within a 'phrase' should be treated as an
'encoded-word' if it meets the syntax rules in section 2.
...
...
(4) A MIME-Version header field is NOT required to be present for
'encoded-word's to be interpreted according to this
specification. One reason for this is that the mail reader is
...
... 'encoded-word's to be interpreted according to this
specification. One reason for this is that the mail reader is
not expected to parse the entire message header before displaying
lines that may contain 'encoded-word's.
...
... displayed, will be indistinguishable from 'special' characters in the
surrounding text. For this and other reasons, it is NOT generally
possible to translate a message header containing 'encoded-word's to
an unencoded form which can be parsed by an RFC 822std11(-> 2822prop) mail reader.
...
...
When displaying a particular header field that contains multiple
'encoded-word's, any 'linear-white-space' that separates a pair of
adjacent 'encoded-word's is ignored. (This is to allow the use of
...
... character set used, it may
(a) display the 'encoded-word' as ordinary text (i.e., as it appears
in the header), (b) make a "best effort" to display using such
characters as are available, or (c) substitute an appropriate message
indicating that the decoded text could not be displayed.
...
... must be able to distinguish 'encoded-word's from 'text', 'ctext', or
'word's, according to the rules in section 6, anytime they appear in
appropriate places in message headers. It must support both the "B"
and "Q" encodings for any character set ...
...
The following are examples of message headers containing 'encoded-
word's:
...
... <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
Subject: Test of new header generator
MIME-Version: 1.0
...
... clarify that encoded-words are allowed in '*text' fields in both
RFC 822std11(-> 2822prop) headers and MIME body part headers, but NOT as parameter
values ...
... state that you can't expect to translate between
1522 and either vanilla 822 or so-called "8-bit headers".
...