1. Introduction

1.1. Scope

This document defines the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of RFC 2822, which itself superseded RFC 822, updating it to reflect current practice and incorporating incremental changes specified in other RFCs.

This document specifies a syntax for text messages only. In particular, it makes no provision for the transmission of images, audio, or other kinds of structured data in electronic mail messages. Several extensions have been published, such as the MIME document series (RFC 2045, RFC 2046, RFC 2049), which describe mechanisms for transmitting such data through electronic mail.

In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains information required to accomplish transmission and delivery (see RFC 5321 for a discussion of the envelope). The contents comprise the object to be delivered to the recipient. This specification applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope.

However, some message systems may use information from the content to create the envelope. This specification is intended to facilitate the acquisition of such information by programs.

This specification is intended as a definition of what message content format is to be passed between systems. Though some message systems locally store messages in this format (eliminating the need for translation between formats), others use different native formats. Local storage is outside the scope of this specification.

Note: This specification is not intended to dictate the internal formats used by sites, the specific message system features they are expected to support, or any characteristics of user interface programs that create or read messages. In addition, this document does not specify the character encoding used for transmission or storage.

1.2. Notational Conventions

1.2.1. Requirements Notation

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in RFC 2119.

Keywords Reference:

Term	Meaning
MUST	Absolute requirement
MUST NOT	Absolute prohibition
SHOULD	Strong recommendation
SHOULD NOT	Strong non-recommendation
RECOMMENDED	Suggested practice
MAY	Optional

1.2.2. Syntactic Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation as described in RFC 5234. Characters are specified either by decimal values (e.g., %d65 for uppercase A, %d97 for lowercase a) or by case-insensitive literal values enclosed in quotation marks (e.g., "A" represents either uppercase or lowercase A).

ABNF Basics:

• Literals: "From:" - case-insensitive
• Decimal values: %d65 - ASCII code 65 (character A)
• Ranges: %d48-57 - digits 0-9
• Repetition: * (zero or more), 1* (one or more), 2*4 (2 to 4 times)
• Optional: [OPTIONAL] - elements in brackets are optional
• Grouping: () - parentheses group elements
• Alternatives: / - choose one

1.2.3. Structure of This Document

This document is organized into several sections.

This section (Section 1) is a brief introduction to the document.

Section 2 lays out the general description of a message and its constituent parts. This is an overview to help the reader understand some of the general principles used in later portions of this document. Any examples in this section MUST NOT be taken as formal specification of any part of the message.

Section 3 specifies the formal ABNF rules for the structure (syntax) of each part of a message and describes the relationship between those parts and their meaning (semantics) in the context of messages. It lists the actual rules (syntax) for the structure of each part of a message, as well as description and explanatory notes on them (semantics). This includes both syntactic and semantic analysis of message subparts that have specific structure. The syntax in Section 3 represents how messages MUST be created. There are also notes in Section 3 indicating whether options in the syntax SHOULD be used over other options.

Both Section 2 and Section 3 describe messages that are legal to generate according to this specification.

Section 4 specifies "obsolete" syntax. Those obsolete syntax elements are referenced in Section 3. The rules of the obsolete syntax are elements that appeared in earlier versions of this specification or have been in wide use on the Internet, but which are no longer to be used when generating messages. As a result, conformant message parsers MUST interpret these elements. However, since items in this syntax have been determined to be non-interoperable or to cause significant problems for message recipients, conformant message creators MUST NOT generate them.

Section 5 details security considerations when implementing this specification.

Appendix A lists examples of different types 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 specification and earlier Internet message specifications.

Appendix C contains acknowledgements.

---

Key Concepts Summary

Message Structure

+-------------------------+
|   Header Section        | ← Defined by this spec
|   - From: alice@...     |
|   - To: bob@...         |
|   - Subject: Hello      |
|   - Date: ...           |
+-------------------------+
|   Blank Line (CRLF)     | ← Required separator
+-------------------------+
|   Body Section          | ← This spec (plain text)
|   Hello World!          |   MIME extends (multimedia)
+-------------------------+

Specification Scope

Content	This Specification	Other Specifications
Message Content Format	✅ Defined	-
Message Transport (SMTP)	❌ Not covered	RFC 5321
Envelope Information	❌ Not covered	RFC 5321
Multimedia Content	❌ Not covered	RFC 2045-2049 (MIME)
Local Storage Format	❌ Not covered	System-specific
Character Encoding	❌ Not specified	Transport layer

Relationship with Related RFCs

RFC 5322 (This RFC)
    ↓ defines
Message Format (IMF)
    ↓ extended by
MIME Series (RFC 2045-2049)
    ↓ transported by
SMTP (RFC 5321)

Document Reading Guide

1. Quick Understanding: Read Sections 1-2 (Overview)
2. Implementation Spec: Study Section 3 (Message generation)
3. Legacy Compatibility: Reference Section 4 (Message parsing)
4. Security: Review Section 5
5. Practical Examples: Browse Appendix A

---

Next: 2. Lexical Analysis of Messages