Connected: An Internet Encyclopedia
Mail Format

Top: Connected: An Internet Encyclopedia
Up: Topics
Up: Functions
Up: Mail

Search: |  | Search Depth: |
Search Type: | String RegEx | Search Options: | NoCase WholeWord

### Mail Format

#### Header Format

RFC 822, one of the most famous RFCs, documents the syntax of Internet mail headers. These headers contain normal, ASCII text that can be written and read by users. The end of the header is a single, empty line, so no blank lines are permitted in headers. Lines indented with whitespace are regarded as continuation lines, so long lines can be split "between lexical tokens". Header lines are formated as a field-name, followed by a colon, followed by field data. No whitespace may appear before the colon, and some field-names impose additional syntax requirements on their data fields. Common header fields are From:, To:, Cc:, Reply-To:, Subject: and Date:

#### Address Format

RFC 822's address specification defines the syntax of an Internet email address. If you can muddle through the over-conceptionalized spec, you find that email addresses look mostly like this:

                                  user@host.network

It is increasingly popular to lose the `host` portion, and let the `network` portion be a top-level DNS domain, writing email addresses more like `user@company.com`. This facility is implemented using DNS-based mail routing.

#### Privacy

Privacy Enhanced Mail (PEM) is documented in RFC 1421, RFC 1422, RFC 1423, and RFC 1424. PEM defines standards for handling encrypted and authenticated mail, but has not been widely implemented, possibly due to questions regarding the patent status of its encryption algorithms.

#### Body Format

Multipurpose Internet Mail Extensions (MIME), documented in RFC 1521 and RFC 1522, defines the standard representation for "complex" message bodies. A "complex" message body doesn't conform to the default of a single, human-readable, ASCII mail message.

MIME defines several new header field - Mime-Version (identifying a MIME document), Content-Type, Content-Transfer-Encoding. The most interesting of these is Content-Type, which defines the content of the document, and comes in seven pre-defined types, each of which have subtypes. An extension mechanism exists for defining new types and subtypes. The Content-Transfer-Encoding defines several encoding mechanisms for binary data that may otherwise be difficult to transport.

#### Summary of MIME Content-types

This is a copy of Appendix F, RFC 1521.

Content-type: | text
--- | ---
Subtypes defined by this document: | plain
Important Parameters: | charset
Encoding notes: | quoted-printable generally preferred if an encoding is needed and the character set is mostly an ASCII superset.
Security considerations: | Rich text formats such as TeX and Troff often contain mechanisms for executing arbitrary commands or file system operations, and should not be used automatically unless these security problems have been addressed. Even plain text may contain control characters that can be used to exploit the capabilities of "intelligent" terminals and cause security violations. User interfaces designed to run on such terminals should be aware of and try to prevent such problems.
Content-type: | multipart
Subtypes defined by this document: | mixed, alternative, digest, parallel.
Important Parameters: | boundary
Encoding notes: | No content-transfer-encoding is permitted.
Content-type: | message
Subtypes defined by this document: | rfc822, partial, external-body
Important Parameters: | id, number, total, access-type, expiration, size, permission, name, site, directory, mode, server, subject
Encoding notes: | No content-transfer-encoding is permitted. Specifically, only "7bit" is permitted for "message/partial" or "message/external-body", and only "7bit", "8bit", or "binary" are permitted for other subtypes of "message".
Content-type: | application
Subtypes defined by this document: | octet-stream, postscript
Important Parameters: | type, padding
Deprecated Parameters: | name and conversions were defined in RFC 1341.
Encoding notes: | base64 preferred for unreadable subtypes.
Security considerations: | This type is intended for the transmission of data to be interpreted by locally-installed programs. If used, for example, to transmit executable binary programs or programs in general-purpose interpreted languages, such as LISP programs or shell scripts, severe security problems could result. Authors of mail-reading agents are cautioned against giving their systems the power to execute mail-based application data without carefully considering the security implications. While it is certainly possible to define safe application formats and even safe interpreters for unsafe formats, each interpreter should be evaluated separately for possible security problems.
Content-type: | image
Subtypes defined by this document: | jpeg, gif
Important Parameters: | none
Encoding notes: | base64 generally preferred
Content-type: | audio
Subtypes defined by this document: | basic
Important Parameters: | none
Encoding notes: | base64 generally preferred
Content-type: | video
Subtypes defined by this document: | mpeg
Important Parameters: | none
Encoding notes: | base64 generally preferred

Connected: An Internet Encyclopedia
Mail Format