Edit

Page

Page title:

Page body:

[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]] 版) <http://tools.ietf.org/html/rfc2046#section-5.1.1>
- [7] '''[CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-5.2.1>'''
]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]] が使われることがあります。

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

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

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

* 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]]]] で表わされることがあります。

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

-*-*-

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

[17] [[MIME]] 以前は色々な[[文字コード]]が[[ヘッダー]]や[[本体]]で使われていました。
[[MIME]] が [[RFC]] になった後でも、20世紀中はまだ [[MIME]]
を使わないメッセージが[[電子メール]]や[[ネットニュース]]で流通していました。
次のような[[文字コード]]が利用されていました:
[FIG(list short)[
- [[JUNETコード]] ([[ISO-2022-JP]] 等)
- [[EUC-JP]]
- [[シフトJIS]]、
- [[ISO/IEC 8859]]
- [[HZ]]
- [[EUC-CN]]
- [[EUC-KR]]
- [[ISO-2022-KR]]
- [[SERA]] ([CODE[<sera>]])

]FIG]

[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]] は、 [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]] <https://datatracker.ietf.org/doc/html/rfc2060#section-6.3.11>

[[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]] 版) <http://ya.maya.st/mail/qmail-violations.html>

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

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

[FIG(quote)[
[FIGCAPTION[
[31] [CITE@en[Concise Binary Object Representation (CBOR)]]
([TIME[2018-02-23 07:30:37 +09:00]])
<https://cbor-wg.github.io/CBORbis/#encodedtext>
]FIGCAPTION]

> Tag 36 is for MIME messages (including all headers), as defined in '''['''RFC2045''']''';

]FIG]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)