Internet
Click on the red underlined text to get to the source
... Comments (RFC) 822std11(-> 2822prop), "Standard for the Format of ARPA Internet Text
Messages" [RFC822], updating it to reflect current practice and
...
... elements that have appeared in
earlier revisions of this standard or have previously been widely
used in Internet messages. As such, these elements MUST be
interpreted by parsers of messages in order to be conformant to this
...
... Appendix A lists examples of different sorts of messages. These
examples are not exhaustive of the types of messages that appear on
the Internet, but give a broad overview of certain syntactic forms.
...
...
Appendix B lists the differences between this standard and earlier
standards for Internet messages.
...
...
The 998 character limit is due to limitations in many implementations
which send, receive, or store Internet Message Format messages that
simply cannot handle more than 998 characters on a line. Receiving
...
...
The syntax as given in this section defines the legal syntax of
Internet messages. Messages that are conformant to this standard
MUST conform to the syntax in this section. If there are options in
this section where one option SHOULD be generated, that is indicated
...
... tokens defined in
the obsolete syntax in section 4. In all cases, these productions
are to be ignored for the purposes of generating legal Internet
messages and MUST NOT be used as part of such a message. However,
when interpreting messages, these tokens MUST be honored as part of
...
... mailbox where the addr-spec address appears alone, without the
recipient's name or the angle brackets. The Internet addr-spec
address is described in section 3.4.1.
...
...
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("@",
...
... locally interpreted string followed by the at-sign character ("@",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
...
... The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name ...
... domain is interpreted as the literal Internet address of the
particular host. In both cases, how addressing ...
... be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet. However, for the purposes of this standard, header
fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace ...
... version. Also, there have
been syntactic elements used in messages on the Internet whose
interpretation have never been documented. Though some of these
syntactic forms MUST NOT be generated according to the grammar in
...
...
Note: This section identifies syntactic forms that any implementation
MUST reasonably interpret. However, there are certainly Internet
messages which do not conform to even the additional syntax given in
this section. The fact that a particular form does not appear in any
section of this document is not justification for computer programs
...
...
Other multi-character (usually between 3 and 5) alphabetic time zones
have been used in Internet messages. Any such time zone whose
meaning is not known SHOULD be considered equivalent to "-0000"
unless there is out-of-band ...
... Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822std11(-> 2822prop), August 1982. ...
... Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045draft ...
... Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045draft, November 1996. ...
... Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046draft ...
... Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII ...
... Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Format of Internet Message Bodies", RFC 2048(-> 4289 | 4288) ...
... Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Format of Internet Message Bodies", RFC 2048(-> 4289 | 4288), November 1996. ...
... Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049draft ...
... Update of Messaging
Standards (DRUMS) Working Group of the Internet Engineering Task
Force (IETF), the chair of DRUMS, the Area Directors ...
...
This appendix contains a list of changes that have been made in the
Internet Message Format from earlier standards, specifically [RFC822]
and [STD3 ...
...
Copyright (C) The Internet Society (2001). All Rights Reserved.
...
... document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
...
... the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
...
... Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
...
... developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
...
...
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
...
... This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
...
... "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ...
...
Funding for the RFC Editor function is currently provided by the
Internet Society.
...