仕様書

意味

[8] MIME型 message/rfc822 は、 本体がカプセル化された RFC 822 メッセージであることを示します >>7。

[10] message/rfc822 は厳密に RFC 822 に適合するものでなくても構いませんし、 RFC 822 における意味と異なるものでも構いません。具体的には、 Usenet ニュースの記事や、 MIME メッセージでも構いません。 >>7

[14] RFC 822 改訂後も特に改訂されることなく放置されていますが、 一般的にはその後の改訂版に従うメッセージにも利用可能であると解されています。

構文

[9] message/rfc822 では、必須のヘッダーに関する制約は次の通り緩和されます: From:、Subject:、 Date: の最低1つはなければなりません >>7。

引数

[11]

charset なんてパラメーターは定義されていません。 charset=us-ascii なんていう意味の無いものをつけてくる MUA (MTA?) があるみたいです。

実装は無視するべきです。 charset パラメーターに 従って無理矢理変換すると、メッセージが壊れる可能性があります。 (charset=utf-16 だったりしたら、変換しないと壊れるだろうがなあ・・・。)

文脈

[24] RFC 822メッセージは、インターネットメールの標準のメッセージ形式として使われています。

[25] ネットニュースのメッセージ形式としても使われていました。 ネットニュースはヘッダーについて独自の規定を持っていました。

[29] MIMEメッセージのメッセージ形式としても使われています。 インターネットメールやネットニュースのメッセージが MIMEメッセージでもある場合もありますが、 単独の MIMEメッセージも存在します。

[26] shimbun ではRFC 822メッセージ・ネットニュースメッセージの形式を拡張したものを用いていました。

[30] MHT として Webページの保存に使われることがあります。 MIME型も message/rfc822 が使われることがあります。

[6] message/rfc822 は、 multipart/digest では Content-Type: 省略時の既定値となっています >>5。

[27] HTTPメッセージ、 DSN、MDN、 TIP などでも類似したメッセージ形式が使われています。 これらも RFC 822メッセージから派生したものではありますが、 独自の規定を持った別のメッセージ形式となっています。

[34] mbox におけるメールメッセージはおおむね RFC 822メッセージですが、 From 行から始まる点が大きな違いですし、 RFC 822 の規定に適合しないこともありますし (例: 編集途中のメール、 受信した不適合のメール、 ニュースメッセージや Thunderbird がフィードから生成したエントリー相当のメッセージなど)、 CTE は binary に相当します。

CTE

[12] message/rfc822 を MIME で使う時は、 7bit, 8bit, binary 以外の内容転送符号化を使ってはなりません >>7。

拡張

[15] RFC 822 メッセージは色々な形で拡張されています。それらも MIME型 message/rfc822 で表わされることがあります。

[20] MIME は、ヘッダーや本体で使う文字コードや MIME型を指定できるように拡張するものです。現在では RFC 822 メッセージの標準機能と化しています (が、 IETF の立場では一応別仕様で、 実装しなくても良い建前となっています)。

[36] MIME以前のメッセージ本体は、 MIME では text/plain; charset=us-ascii に相当すると説明されることが多いですが、 実際には様々な文字コード、 様々な構文が使われていました。

[17] MIME 以前は色々な文字コードがヘッダーや本体で使われていました。 MIME が RFC になった後でも、20世紀中はまだ MIME を使わないメッセージが電子メールやネットニュースで流通していました。 次のような文字コードが利用されていました:

[18] uuencode などで添付ファイルを符号化して本体に含めることがよくありました。

[19] PGP などの電子署名を ASCII Armor として本体に含めることがよくありました。

[21] RFC 934、RFC 1154、RFC 1505、 PEM は 各種 MIME型に相当する本体の拡張方法を提案していましたが、 それほど普及せず、 MIME に駆逐されました。

[37] MUA、ニュースリーダー等のインターネットメッセージを読み書きする利用者エージェント等は、 こうしたMIME 以前のメッセージ形式をもはや生成するべきではありません。 しかし、既存のデータとの互換性のため、こうした MIME 以前のメッセージも適切に処理できるよう、 最大限の試みをするべきです。

[38] ただこうした古い慣習は明文化されていないものも多く、 かつて明文化されていたものも時代の経過とともに情報が失われており、 実装しづらくなっているのが実情です。 テストのための実データも入手困難になりつつあります。

[39] 情報や実データが入手しづらいということは、それが必要になる状況ももはやほとんどないということでもあります。 新たなデータが生成されることはほぼないのですし、 メールは個人間でのやり取りが基本ですから、 今現在所持していない人が新たに入手することはほぼありません。

[40] ただ、過去のメーリングリストやニュースグループのアーカイブなど、 そうしたデータに接する機会がまったく皆無ということもありません。 技術史、ネットワーク社会発展史などの方面からそうしたデータにアクセスする人にとっては、 そうしたデータを読むための手段が維持されることに意義はあります。

[16] 8bit-MIMEtransport は、 8bit 転送路を提供する SMTP の拡張です。これを使って 8bit の範囲に拡張された RFC 822 のバリエーションが利用されることがあります。 8bit-MIMEtransport はそれを「8bit MIME」などと呼んでいます。 しかし RFC 5322 に至るまで電子メールのメッセージ構文の仕様書はこれを明示的には認めていません。

[22] BINARYMIME は、 binary 転送路を提供する SMTP の拡張です。これを使って binary の範囲に拡張された RFC 822 のバリエーションが利用されることがあります。 しかし RFC 5322 に至るまで電子メールのメッセージ構文の仕様書はこれを明示的には認めていません。

[33] rfc2060, 2021-06-09T03:39:14.000Z https://datatracker.ietf.org/doc/html/rfc2060#section-6.3.11

IMAP4 の APPEND の引数: RFC 822メッセージ, 8bit, 草稿では必須のヘッダーを省略可

[32] 822/XML

[35] RFC 822 構文の影響: ネットニュース, MIMEメッセージ, message/external-body, DSN, MDN, HTTP, RTSP, SIP, CPIM, application/x-kddi-auc, FIPA MTSメッセージ

関連

[4] ヘッダー部だけを取り出した text/rfc822-headers もあります。

歴史

メモ

[1] qmail RFC violations (2005-12-14 00:00:05 +09:00 版) http://ya.maya.st/mail/qmail-violations.html

[2] FGA: Some of what is said about "qmail" is wrong (2004-12-08 10:45:51 +09:00 版) http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutBareLFs

[3] RFC 7103 - Advice for Safe Handling of Malformed Messages (2014-01-27 23:43:50 +09:00 版) http://tools.ietf.org/html/rfc7103