[28] RFC 822メッセージは、 インターネットメールなどで用いられているメッセージ形式です。
[23] message/rfc822 は、電子メールのメッセージ形式として広く用いられているものです。
[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。
| charset | mime.charset | 非標準 | charset |
x-spam-type | 非標準 | spam 処理情報 |
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 に相当します。
[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, https://datatracker.ietf.org/doc/html/rfc2060#section-6.3.11
IMAP4 の APPEND の引数:
RFC 822メッセージ, 8bit, 草稿では必須のヘッダーを省略可
[35] RFC 822 構文の影響:
ネットニュース,
MIMEメッセージ,
message/external-body,
DSN,
MDN,
HTTP,
RTSP,
SIP,
CPIM,
application/x-kddi-auc,
FIPA MTSメッセージ
[4]
ヘッダー部だけを取り出した text/rfc822-headers
もあります。
A media type of "message/rfc822" indicates that the body contains an encapsulated message, with the syntax of an RFC 822 message. However, unlike top-level RFC 822 messages, the restriction that each "message/rfc822" body must include a "From", "Date", and at least one destination header is removed and replaced with the requirement that at least one of "From", "Subject", or "Date" must be present.
媒体型 "message/rfc822" は、本文が RFC 822 メッセージの構文の カプセル化メッセージであることを示します。しかし、最上位 RFC 822 メッセージとは異なり、各 "message/rfc822" 本文が "From", "Date", 最低一つの宛先頭を入れなければならないという制限は撤廃し、 代わりに要件を "From", "Subject", "Date" の最低一つが無ければならない とします。
It should be noted that, despite the use of the numbers "822", a "message/rfc822" entity isn't restricted to material in strict conformance to RFC822, nor are the semantics of "message/rfc822" objects restricted to the semantics defined in RFC822. More specifically, a "message/rfc822" message could well be a News article or a MIME message.
注意されたいこととしては、「822」という番号を使ってはいますが、 "message/rfc822" 実体は RFC 822 に厳密に適合するものに制限しませんし、 "message/rfc822" 物体の意味を RFC 822 で定義された意味にも制限しません。 具体的には、 "message/rfc822" メッセージは、ニュース投稿や MIME メッセージにも使うことが出来ます。
No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047.
"7bit", "8bit", "binary" 以外の符号化は "message/rfc822" 実体の本文には 認められていません。メッセージ頭領域は常にどんな場合も US-ASCII で、本文中のデータは符号化されていても構いません。その場合はカプセル化 メッセージの Content-Transfer-Encoding 頭領域がこれを反映しています。 カプセル化メッセージの頭中の非 US-ASCII 文は、 RFC 2047 で説明されている 方法を使って記述出来ます。
[1] qmail RFC violations ( 版) http://ya.maya.st/mail/qmail-violations.html
[2] FGA: Some of what is said about "qmail" is wrong ( 版) http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutBareLFs
[3] RFC 7103 - Advice for Safe Handling of Malformed Messages ( 版) http://tools.ietf.org/html/rfc7103
Tag 36 is for MIME messages (including all headers), as defined in [RFC2045];