822

RFC 822 (電子メール)

[1] RFC 822 は、長年インターネットメールメッセージ形式を規定するインターネット標準だった RFC です。

[2] RFC 822 は出版から十数年を経て改訂され RFC 2822 となりました。その後更に改訂されて RFC 5322 となっています。

[21] メッセージ形式に固有の名称がないため、改訂により廃止された現在もあえて RFC 822 形式と呼び続けていることがあります。

メッセージ形式

[17] RFC 822インターネット電子メールで使われるメッセージ形式を規定しています。 この形式は MIME では message/rfc822 と呼ばれています。 message/rfc822

[18] SMTP を使う標準のインターネットメールの他、 USENET (UUCPNNTP) や MMS など他のプロトコルでも使われています。 message/rfc822

[19] ヘッダー部空行本体で構成され、ヘッダーは名前、:、 本体で構成されるといった本メッセージ形式は、 HTTP をはじめとする様々なアプリケーションプロトコルの設計に影響を与えました。

名前としての「RFC 822」

[7] RFC 822 が規定するメッセージ形式は、明確な呼称がありません。 (RFC 2822Internet Message Format と呼んでいるようですが...) RFC 822 により規定されているため、しばしば「RFC 822 (の形式)」や 「822」などと呼ばれます。 MIME型message/rfc822 となっています。

[8] RFC 822廃止された後も、(他に呼びようがないので) RFC 822 と引き続き呼ばれる場合があります。しかし廃止された RFC の番号で呼び続けるのもおかしな話なので、 RFC 2822RFC 5322 の形式と呼ぶこともあります (が知名度が低いのが難点です)。

STD 11

[4] RFC 822インターネット標準であり、 STD 11 という番号が割り振られています。

[5] RFC 822RFC 2822廃止されましたが、インターネット標準であった RFC 822 に対し、全面改訂である RFC 2822提案標準でしかないため、 STD 11 は引き続き RFC 822 を表すという矛盾した状況になっています。 RFC 5322インターネット標準ではありません。

[6] 長い年月を経て実情に則さなくなり改訂された旧版である RFC 822 が「インターネット標準」と呼ばれ、より実質的な標準に近いはずの RFC 2822 が手続き上の理由で「提案」段階にとどまっているのはおかしな話ですが、 IETF ではそういうものだと扱われているようです。

RFC 1123

[14] RFC 822RFC 1123 により一部が更新され、 年号の扱い (2000年問題対策) などが改められています。

[15] しかし、これはしばしば (気付かれずに) 無視されていました。

[16] 他の RFC が古い RFC の一部を改訂する場合にはよくあることです。 RFC 2822 による全面改訂までこの状況が続きました。
[3] ほとんどの実装は、 RFC 1123 に従っていました。

ABNF

[9] RFC 822 が構文の定義のために使っていた書式である ABNF (RFC 822のABNF) は、電子メール関連仕様をはじめ多くの IETF の仕様書で流用されました。

[10] これは後に独立した RFC になっています。 RFC 822 の改訂である RFC 2822 も、この新しい ABNFRFC を採用する形になっています。 ABNF

日時形式

[11] RFC 822の日時形式は、電子メールをはじめ多くの仕様で採用され、 一時はインターネットアプリケーション層における日時形式事実上の標準と考えられていました。

[12] その後 RFC 3339ISO 8601 ベースの新しい日時形式を規定したことにより、 それ以後の仕様がそちらを採用するようになりました。もちろんそれ以前から RFC 822の日時形式を採用していた仕様は、現在も引き続き RFC 822の日時形式を使っています。

メモ

電子メール プロトコル

[22] mparse Files http://users.erols.com/blilly/mparse/index.html

[20] PEP 0345 -- Metadata for Python Software Packages 1.2 | Python.org ( 版) https://www.python.org/dev/peps/pep-0345/

To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe ("|") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2] .