[28] [DFN[RFC 822メッセージ]]は、 [[インターネットメール]]などで用いられている[[メッセージ形式]]です。 [23] [DFN[[CODE(MIME)@en[[[message/rfc822]]]]]] は、[[電子メール]]の[[メッセージ形式]]として広く用いられているものです。 * 仕様書 [REFS[ - [[RFC 5322]] - [5] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) - [7] '''[CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) ''' ]REFS] * 意味 [8] [[MIME型]] [CODE(MIME)@en[[[message/rfc822]]]] は、 [[本体]]がカプセル化された [[RFC 822]] [[メッセージ]]であることを示します [SRC[>>7]]。 [10] [CODE(MIME)@en[[[message/rfc822]]]] は厳密に [[RFC 822]] に適合するものでなくても構いませんし、 [[RFC 822]] における意味と異なるものでも構いません。具体的には、 [[Usenet]] [[ニュース]]の[[記事]]や、 [[MIME]] [[メッセージ]]でも構いません。 [SRC[>>7]] [14] [[RFC 822]] 改訂後も特に改訂されることなく放置されていますが、一般的にはその後の改訂版に従う[[メッセージ]]にも利用可能であると解されています。 * 構文 [9] [CODE(MIME)@en[[[message/rfc822]]]] では、必須の[[ヘッダー]]に関する制約は次の通り緩和されます: [CODE(822)@en[[[From:]]]]、[CODE(822)@en[[[Subject:]]]]、 [CODE(822)@en[[[Date:]]]] の最低1つはなければ[['''なりません''']] [SRC[>>7]]。 * 引数 [11] ,charset ,mime.charset ,非標準 ,charset ,[CODE(MIME)[[[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型]]も [CODE[message/rfc822]] が使われることがあります。 [34] [[mbox]] における[[メールメッセージ]]はおおむね [[RFC 822メッセージ]]ですが、 [[[CODE[From ]]行]]から始まる点が大きな違いですし、 [[RFC 822]] の規定に[[適合]]しないこともありますし (例: 編集途中の[[メール]]、受信した不適合の[[メール]]、 [[ニュースメッセージ]]や [[Thunderbird]] が[[フィード]]から生成した[[エントリー]]相当の[[メッセージ]]など)、 [[CTE]] は [CODE[binary]] に相当します。 [27] [[HTTPメッセージ]]、 [[DSN]]、[[MDN]]、 [[TIP]] などでも類似した[[メッセージ形式]]が使われています。これらも [[RFC 822メッセージ]]から派生したものではありますが、独自の規定を持った別の[[メッセージ形式]]となっています。 [41] その他色々な[[プロトコル]]や[[データ形式]] (特に[[平成時代]]初期頃に開発されたもの) が [[RFC 822メッセージ]]の影響を受けて似たような構文を持っています (>>35) が、 [[RFC 822]] そのものに従っていることは稀で、「似て非なるもの」に過ぎないことが普通です。 -*-*- [6] [CODE(MIME)@en[message/rfc822]] は、 [CODE(MIME)@en[[[multipart/digest]]]] では [CODE(MIME)@en[[[Content-Type:]]]] 省略時の既定値となっています [SRC[>>5]]。 * CTE [12] [CODE(MIME)@en[[[message/rfc822]]]] を [[MIME]] で使う時は、 [CODE(MIME)@en[[[7bit]]]], [CODE(MIME)@en[[[8bit]]]], [CODE(MIME)@en[[[binary]]]] ''以外''の[[内容転送符号化]]を使ってはなりません [SRC[>>7]]。 * 拡張 [15] [[RFC 822]] メッセージは色々な形で拡張されています。それらも [[MIME型]] [CODE(MIME)@en[[[message/rfc822]]]] で表わされることがあります。 ;; [42] [[MIME]] の定義上それを [CODE[message/rfc822]] で表すことが必ずしも適切とは限りませんが、事実としてそう利用されています。 [20] [[MIME]] は、[[ヘッダー]]や[[本体]]で使う[[文字コード]]や [[MIME型]]を指定できるように拡張するものです。現在では [[RFC 822]] [[メッセージ]]の標準機能と化しています (が、 [[IETF]] の立場では一応別仕様で、実装しなくても良い建前となっています)。 ;; [43] その建前も既に30年が経過していて、非常に古いメッセージとの互換性のために必要な場合を除けば、新規の[[インターネットメール]]の送受信に関しては実質的に [[MIME]] と一体化していると考える他に選択肢はありません。 -*-*- [36] [DFN[MIME以前のメッセージ本体]]は、 [[MIME]] では [CODE[text/plain; charset=us-ascii]] に相当すると説明されることが多いですが、実際には様々な[[文字コード]]、様々な構文が使われていました。 [17] [[MIME]] 以前は色々な[[文字コード]]が[[ヘッダー]]や[[本体]]で使われていました。 [[MIME]] が [[RFC]] になった後でも、20世紀中はまだ [[MIME]] を使わないメッセージが[[電子メール]]や[[ネットニュース]]で流通していました。次のような[[文字コード]]が利用されていました: [FIG(list short)[ - [[JUNETコード]] ([[ISO-2022-JP]], [[ISO-2022-JP-2]], [[ISO-2022-INT]] 等) - [[EUC-JP]] - [[シフトJIS]] - [[ISO/IEC 8859]] - [[HZ]] - [[EUC-CN]] - [[EUC-KR]] - [[ISO-2022-KR]] - [[VIQR]] - [[SERA]] ([CODE[]]) ]FIG] [18] [[uuencode]] などで[[添付ファイル]]を[[符号化]]して本体に含めることがよくありました。 [[MIME]] 開発後も[[インターネットニュース]]などでかなり使われ続け、 [[MUA]] で [[MIME]] と [[uuencode]] のどちらで送信するか選べるものも普及していました (どれだけの人が手動で設定変更していたかは謎ですが)。 [44] [[shar]] 形式の[[添付ファイル]]もしばしば使われました。 [19] [[PGP]] などの[[電子署名]]を [[ASCII Armor]] として本体に含めることがよくありました。 [[PGP/MIME]] 開発後もしばらくその形態で使われ続けていました。 ;; [[メール本文]]も参照。 [21] [[RFC 934]]、[[RFC 1154]]、[[RFC 1505]]、 [[PEM]] は各種 [[MIME型]]に相当する[[本体]]の拡張方法を提案していましたが、それほど普及せず、 [[MIME]] に駆逐されました。 [37] [[MUA]]、[[ニュースリーダー]]等の[[インターネットメッセージ]]を読み書きする[[利用者エージェント]]等は、こうした[[MIME]] 以前の[[メッセージ]]形式をもはや[[生成]]するべきではありません。しかし、既存のデータとの互換性のため、こうした [[MIME]] 以前の[[メッセージ]]も適切に処理できるよう、最大限の試みをするべきです。 [38] ただこうした古い慣習は明文化されていないものも多く、かつて明文化されていたものも時代の経過とともに情報が失われており、実装しづらくなっているのが実情です。テストのための実データも入手困難になりつつあります。 [39] 情報や実データが入手しづらいということは、それが必要になる状況ももはやほとんどないということでもあります。新たなデータが[[生成]]されることはほぼないのですし、 [[メール]]は個人間でのやり取りが基本ですから、今現在所持していない人が新たに入手することはほぼありません。 [40] ただ、過去の[[メーリングリスト]]や[[ニュースグループ]]の[[アーカイブ]]など、そうしたデータに接する機会がまったく皆無ということもありません。技術史、ネットワーク社会発展史などの方面からそうしたデータにアクセスする人にとっては、そうしたデータを読むための手段が維持されることに意義はあります。 -*-*- [16] [[8bit-MIMEtransport]] は、 [CODE(MIME)@en[[[8bit]]]] [[転送路]]を提供する [[SMTP]] の拡張です。これを使って [CODE(MIME)@en[[[8bit]]]] の範囲に拡張された [[RFC 822]] のバリエーションが利用されることがあります。 [[8bit-MIMEtransport]] はそれを「8bit MIME」などと呼んでいます。しかし [[RFC 5322]] に至るまで[[電子メール]]のメッセージ構文の仕様書はこれを明示的には認めていません。 [22] [[BINARYMIME]] は、 [CODE(MIME)@en[[[binary]]]] [[転送路]]を提供する [[SMTP]] の拡張です。これを使って [CODE(MIME)@en[[[binary]]]] の範囲に拡張された [[RFC 822]] のバリエーションが利用されることがあります。しかし [[RFC 5322]] に至るまで[[電子メール]]のメッセージ構文の仕様書はこれを明示的には認めていません。 [33] [CITE@en[rfc2060]], [TIME[2021-06-09T03:39:14.000Z]] [[IMAP4]] の [CODE[APPEND]] の引数: [[RFC 822メッセージ]], [CODE[8bit]], 草稿では必須の[[ヘッダー]]を省略可 -*-*- [32] [[822/XML]] [35] [[RFC 822]] 構文の影響: [[ネットニュース]], [[MIMEメッセージ]], [CODE[message/external-body]], [[DSN]], [[MDN]], [[HTTP]], [[RTSP]], [[SIP]], [[CPIM]], [CODE[application/x-kddi-auc]], [[FIPA MTSメッセージ]] * 関連 [4] [[ヘッダー部]]だけを取り出した [CODE(MIME)@en[text/rfc822-headers]] もあります。 * 歴史 [FIG(quote)[ [FIGCAPTION[ [13] RFC 2046 5.2.1. RFC822 Subtype ]FIGCAPTION] > 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 で説明されている方法を使って記述出来ます。 ]FIG] * メモ [1] [CITE[qmail RFC violations]] ([TIME[2005-12-14 00:00:05 +09:00]] 版) [2] [CITE[FGA: Some of what is said about "qmail" is wrong]] ([TIME[2004-12-08 10:45:51 +09:00]] 版) [3] [CITE@en[RFC 7103 - Advice for Safe Handling of Malformed Messages]] ([TIME[2014-01-27 23:43:50 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [31] [CITE@en[Concise Binary Object Representation (CBOR)]] ([TIME[2018-02-23 07:30:37 +09:00]]) ]FIGCAPTION] > Tag 36 is for MIME messages (including all headers), as defined in '''['''RFC2045''']'''; ]FIG]