[7] message/external-body
は、
実際の本体データが含まれず、参照だけ含まれていることを示します >>6。
[20] message/external-body
はその参照するデータを「透過的」
に表すもので、外部参照するメッセージ自身を表すものではありません >>6。
[8] 本体は、カプセル化されたメッセージのヘッダーと、空行です。 その後に phantom body を含めることもできます。 >>6
Content-Type:
です。こちらのヘッダーは、
取得される実体のヘッダーです。[11] カプセル化されたヘッダーには、 Content-ID:
ヘッダーがなければなりません >>6。
[9] phantom body は、ほとんどの場合は無視されますが、
access-type
によっては補助情報を含めることができます >>6。
Content-Tranfer-Encoding:
を指定しても、それは phantom body について記述したことにはなりません。dir | value | (ディレクトリ名) | ? | [MIME] |
url | value | URL | url | RFC 2017 |
dir パラメーターは、 RFC 1521 の BNF にだけ定義されています。 directory の誤植みたいですが、仕方無いので実装は これにも対応していた方が良いかもしれません。
local-file, aftp では、 site パラメーターの値は domain / aste-domain
[16] access-type
は必須です >>6。
[1] message/external-body
の参照先は、
access-type
引数の値 (アクセス型) により決まります。
RFC 1873 urn:ietf:rfc:1873 (訳 http://suika.fam.cx/~wakaba/document/rfc-ja/rfc1873-ja) で定義されています。
同じメッセージ中の他の他部分実体を参照するのに使います。
パラメーターは定義されていません。 RFC 1873 では必須のパラメーター 無しとなっていますが、当然 access-type が必要です。
参照先 CID は、 message/external-body の外側の実体の頭 の Content-ID:領域に書くようです。 external-body 内部の 頭ではありません。
しかし、 MIME (RFC 1521, 2046) によれば、内部の頭での CID 領域が必須です。実装は外側に CID が無い場合に、 内側に CID がないか確認して、あればそれを使うのが良さげです。
逆に、送信側実装は、外側と同じ CID を内側にも入れると 良いかもしれませんけど、よく分かりません。 (外側 CID は本来的には、 message/external-body 実体の ID なんですよね? だからそこを参照先 CID に使うのが 間違ってるような。)
RFC 2017 urn:ietf:rfc:2017 で定義されてます。 BNF は次の通り。
RFC 2017 から抜粋。
(1) A check is made to make sure that all occurrences of SPACE, CTLs, double quotes, backslashes, and 8-bit characters in the URL string are already encoded using the URL encoding scheme specified in RFC 1738. Any unencoded occurrences of these characters must be encoded. Note that the result of this operation is nothing more than a different representation of the original URL.
URL 文字列中の SPACE, CTL, 二重引用符, 逆斜線, 8ビット文字 が既に RFC 1738 で規定されている URL 符号化方式で符号化されているか 確認する。符号化されていないこれらの文字があれば、符号化 しなければなりません。この捜査の結果は元の URL の違った表現に 過ぎないことに注意して下さい。
訳注: SP / CTL / <"> / "\" / %x80-FF は、 URI/URL 中では(URI 符号化しないと)使えません。けど、実際にはしばしば そういうのが使われてます。 ("URL" 接続型では使われてないとは 思いますが・・・。) ですから、この確認はほとんどの場合で必須です。]]
(2) The resulting URL string is broken up into substrings of 40 characters or less.
結果の URL 文字列を40文字以下の小文字列に分割する。
(3) Each substring is placed in a URL-parameter string as a URL-word, separated by one or more spaces. Note that the enclosing quotes are always required since all URLs contain one or more colons, and colons are tspecial characters [RFC 1521].
各小文字列を URL-parameter 文字列中に、 一つ以上の間隔で区切られた URL-word として入れる。 URL は1つ以上のコロンを含み、コロンは tspecial 文字ですから、 囲み引用符は常に必要であることに注意して下さい。
Extraction of the URL string from the URL-parameter is even simpler: The enclosing quotes and any linear whitespace are removed and the remaining material is the URL string.
URL 文字列を URL-parameter から取り出すのはより簡単です。 囲んでいる引用符と行空白間隔を取り除けば、残ったものが URL 文字列です。
(引用・翻訳ここまで)
RFC 2017 は RFC 2231 の方法が規定される前ですから、こうした仕様に なってます。ですが、現在では普通に URL を(実際の)パラメーター値 とする RFC 2231 方式の拡張パラメーターにするのが良いかもしれません。
空白を入れつつも RFC 2231 方式で分割するのは、 みっともないのであまり宜しくないと思います。けど、解釈する 実装はそういうのにも対応するべきでしょう。
特に HTTP なんかだと、 URL と実際のデータが一対一対応していないことが よくあります。 RFC 2017 によると、取り寄せたデータと external-body 本文に書いてある content-type が一致する場合のみ そのデータを使える (正しいと見なせる) としています。
実装は、場合によっては CT だけでなくて Content-Language とかも 同様の扱いにするのが良いと思われます。それから、取り寄せ時に HTTP なら Accept:領域やAccept-Language:領域を使うようにする のが良いと思います。
[21] message/external-body
を含むメッセージの「外側」
ヘッダーと、参照される「内側」ヘッダーは、
message/partial
と同じ規則により併合しなければなりません >>6。
[18] 受信した利用者エージェントが自動的に処理すると、 受信者が意図しない行為を送信者が指示できてしまうかもしれません。 従って利用者エージェントは明示的に受信者の確認を得てから取得するべきです。 >>6
[19] 悪意のある送信者は、受信者の行為を追跡する意図を持っているかもしれませんから、 注意が必要です。
RFC 1486, 1528 に例が載ってます。 (別に external-body の例として 載ってるわけではありませんけどねー)
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----- =_aaaaaaaaaa0" Content-Description: pointers to ftp and e-mail access
------- =_aaaaaaaaaa0 Content-Type: message/external-body; access-type="mail-server"; server="archive-server@ftp.ics.uci.edu"
Content-Type: application/octet-stream; type="tar"; x-conversions="x-compress" Content-ID: <4599.735726126.1@dbc.mtview.ca.us>
mimesend mrose/tpc/rp.tar.Z
------- =_aaaaaaaaaa0 Content-Type: message/external-body; access-type="anon-ftp"; name="rp.tar.Z"; directory="mrose/tpc"; site="ftp.ics.uci.edu"
Content-Type: application/octet-stream; type="tar"; x-conversions="x-compress" Content-ID: <4599.735726126.2@dbc.mtview.ca.us>
------- =_aaaaaaaaaa0--
CID の例
MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary=tiger-lily
--tiger-lily Content-Type: image/jpeg Content-ID: <950323.1552@XIson.com>
AAAcdb... --tiger-lily Content-type: Message/External-Body; access-type=content-id Content-ID: <950323.1552@XIson.com> Content-Description: This body part is duplicated by reference
--tiger-lily--
RFC 1521, 2046 では message/external-body の内側の頭で CID が必須です。ですから、最終部分は次のようにするのが 正しいことになります。
--tiger-lily Content-type: Message/External-Body; access-type=content-id Content-ID: <950323.1552@XIson.com> Content-Description: This body part is duplicated by reference Content-ID: <some.content.id@external.body.example> --tiger-lily--
上の "Content-ID" 接続型の説明も参照してください。
URL の例
Content-type: message/external-body; access-type=URL; URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/ 8/9/10/11/12/13/14/15/16/17/18/20/21/ file.html"
Content-type: text/html Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
なお、これは RFC 1521/2046 的には間違いです。 (上の例参照)
RFC 2231 の方法を使うと、
Content-Type: message/external-body; access-type=URL; URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
は次のようにも表せます。
Content-Type: message/external-body; access-type=URL; URL*0="ftp://"; URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
The Content-MD5 header may also be placed in the encapsulated headers of an object of type message/external-body, to be used to verify that the retreived and decoded data are the same data that were initially referenced.
Content-MD5 頭は、 message/external-body 型の物体のカプセル化された頭 にも置くことが出来ます。取り出して復号したデータが最初に参照していた データと同じ物であるかを確認するのに使います。
In some scenarios, the user operating the client software might want to specify a URL for remote data rather than a local file. In this case, is there a way to allow the browser to send to the client a pointer to the external data rather than the entire contents? This capability could be implemented, for example, by having the client send to the server data of type "message/external-body" with "access-type" set to, say, "uri", and the URL of the remote data in the body of the message.
幾つかの筋書きでは、クライアント・ソフトウェアを操作する利用者 は遠隔データに local ファイルではなく遠隔データの URL を指定したいと思うかもしれません。この場合、閲覧者が クライアントに内容全体ではなく外部データ参照を送る方法はあるでしょうか。 この機能は。例えばクライアントがサーバーにデータを型 "message/external-body" で "access-type" を "uri" にして、 メッセージの本文中に遠隔データの URL を入れることで実装出来ます。
RFC 1341 と 1521/2046 では、内側の Content-ID についての規定が 違います。 (1341 では必須でない。) "Content-ID" 接続型 の節などを参照。
実際の外部実体を統合する場合の手順が、 RFC 1341/1521/2046 でそれぞれ微妙に違います。但し、 external-body ではあまり影響はないでしょう。 message/partial媒体型参照。
The external-body subtype indicates that the actual body data are not included, but merely referenced. In this case, the parameters describe a mechanism for accessing the external data.
external-body 亜型は、実際の本文データが含まれておらず、単に参照されている だけであることを示します。この場合、パラメーターに外部データに接続する 方法を指定します。
When a MIME entity is of type "message/external-body", it consists of a header, two consecutive CRLFs, and the message header for the encapsulated message. If another pair of consecutive CRLFs appears, this of course ends the message header for the encapsulated message. However, since the encapsulated message's body is itself external, it does NOT appear in the area that follows. For example, consider the following message:
MIME 実体が型 "message/external-body" である場合、これは頭, 2つの 連続した CRLF, カプセル化されたメッセージのメッセージ頭から 構成されます。更に連続した2つの CRLF が出現した場合、これは勿論 カプセル化されたメッセージの終端となります。しかし、カプセル化された メッセージの本文自体は外部にあるので、続く領域には現れません。 例えば、次のメッセージを考えてみます。
Content-type: message/external-body; access-type=local-file; name="/u/nsb/Me.jpeg"
Content-type: image/jpeg Content-ID: <id42@guppylake.bellcore.com> Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
The area at the end, which might be called the "phantom body", is ignored for most external-body messages. However, it may be used to contain auxiliary information for some such messages, as indeed it is when the access-type is "mail-server". The only access-type defined in this document that uses the phantom body is "mail-server", but other access-types may be defined in the future in other specifications that use this area.
終わりのところの領域は、「見かけの本文」と呼びますが、ほとんどの external-body メッセージでは無視します。しかし、これは access-type が "mail-server" の時のように、メッセージの 補助情報を入れるのに使われるかもしれません。この文書の中で定義している access-type で見掛けの本文を使うのは "mail-server" だけですが、 他の access-type が将来他の仕様書で、この領域を使うように 定義されるかもしれません。
The encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field to give a unique identifier by which to reference the data. This identifier may be used for caching mechanisms, and for recognizing the receipt of the data when the access-type is "mail-server".
すべての "message/external-body" 実体のカプセル化された頭は、 データを参照するために与える唯一識別子を Content-ID 頭領域で 含めていなければなりません。この識別子はキャッシュ機構で 使われるかもしれません。また、 access-type が "mail-server" の場合のデータの受け取りの認知に使われるかもしれません。
Note that, as specified here, the tokens that describe external-body data, such as file names and mail server commands, are required to be in the US-ASCII character set.
なお、ここで規定する通り、 external-body を説明するファイル名や メイル・サーバー命令のような字句は、 US-ASCII 文字集合である 必要があります。
If this proves problematic in practice, a new mechanism may be required as a future extension to MIME, either as newly defined access-types for "message/external-body" or by some other mechanism.
これが実際に問題があると認められる場合は、新しい機構が MIME の将来の拡張か、新しい "message/external-body" の access-type の定義か、その他の機構が必要かもしれません。
As with "message/partial", MIME entities of type "message/external-body" MUST have a content-transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content-transfer-encoding of "8bit" or "binary" is explicitly prohibited for entities of type "message/external-body".
"message/partial" 同様、型 "message/external-body" の MIME 実体は、 7bit (既定値) の cte でなければなりません。特に、 バイナリや8ビットの転送に対応した環境であっても、 "8bit" や "binary" の cte の使用は、型 "message/external-body" については 明白に禁止します。
The parameters that may be used with any "message/external-body" are:
どの "message/external-body" とも使えるパラメーターは、次の通りです。
(1) ACCESS-TYPE -- A word indicating the supported access mechanism by which the file or data may be obtained. This word is not case sensitive. Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for experimental values beginning with "X-", must be registered with IANA, as described in RFC 2048. This parameter is unconditionally mandatory and MUST be present on EVERY "message/external-body".
ファイルやデータを得ることが出来る, 対応接続方式を示す言葉。 この言葉は大文字・小文字を区別しません。値は "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE", "MAIL-SERVER" を含みますが、これに限りません。 "X-" で始まる実験用値を除く 将来の値は、 RFC 2048 で説明する通り IANA で登録しなければなりません。 このパラメーターは無条件に必須で、各 "message/external-body" に必ずなければなりません。
(2) EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as extended by RFC 1123 to permit 4 digits in the year field) after which the existence of the external data is not guaranteed. This parameter may be used with ANY access-type and is ALWAYS optional.
それ以降外部データの存在が保証されなくなる日付 (RFC 822 の "date-time" 構文の、 RFC 1123 で4桁年号を使えるように 拡張したもので)。このパラメーターはどの access-type でも使うことが出来て、常に省略可能です。
(3) SIZE -- The size (in octets) of the data. The intent of this parameter is to help the recipient decide whether or not to expend the necessary resources to retrieve the external data. Note that this describes the size of the data in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter may be used with ANY access-type and is ALWAYS optional.
データの大きさ (オクテットで)。このパラメーターの意図は、 外部データを取り出すのに必要な資源を費やすかどうか 受取人が決めるのを助けることです。なお、ここでは 正規形のデータの大きさ、つまり CTE を施す前や データを復号した後のものを記述します。このパラメーターはどの access-type でも使うことが出来て、常に省略可能です。
(4) PERMISSION -- A case-insensitive field that indicates whether or not it is expected that clients might also attempt to overwrite the data. By default, or if permission is "read", the assumption is that they are not, and that if the data is retrieved once, it is never needed again. If PERMISSION is "read-write", this assumption is invalid, and any local copy must be considered no more than a cache. "Read" and "Read-write" are the only defined values of permission. This parameter may be used with ANY access-type and is ALWAYS optional.
クライアントがデータを上書きしようとも出来るかどうかを示す、 大文字・小文字を区別しない領域。既定値または permission が "read" の場合、出来ないと仮定し、データを一度取り出せば、 二度とまた取り出す必要はありません。 PERMISSION が "read-write" の場合は、この仮定は出来ず、 local な複製はキャッシュ以上の 何者でもないと考えなければなりません。 "Read" と "Read-write" だけが定義された permission の値です。このパラメーターはどの access-type でも使うことが出来て、常に省略可能です。
The precise semantics of the access-types defined here are described in the sections that follow.
ここで定義した access-typeの正確な意味は、以降の節で説明します。
An access-type of FTP or TFTP indicates that the message body is accessible as a file using the FTP [RFC-959] or TFTP [RFC-783] protocols, respectively. For these access-types, the following additional parameters are mandatory:
FTP や TFTP の access-type は、メッセージ本文がそれぞれ FTP や TFTP のプロトコルを使って接続出来ることを示します。これらの access-type には、次の追加のパラメーターが必須です。
(1) NAME -- The name of the file that contains the actual body data.
実際の本文データを含むファイルの名前
(2) SITE -- A machine from which the file may be obtained, using the given protocol. This must be a fully qualified domain name, not a nickname.
指定されたプロトコルを使ってファイルを得ることが出来る機械。 これは愛称ではなく、完全修飾ドメイン名でなければなりません。
(3) Before any data are retrieved, using FTP, the user will generally need to be asked to provide a login id and a password for the machine named by the site parameter. For security reasons, such an id and password are not specified as content-type parameters, but must be obtained from the user.
データを取り出す前に、 FTP を使う場合、 site パラメーターで名前指定された機械のログイン識別子と合言葉 を示すよう利用者に尋ねる必要が通常あります。 安全性の理由から、この識別子と合言葉は content-type パラメーター として指定しませんが、利用者から得なければなりません。
In addition, the following parameters are optional:
加えて、次の省略可能なパラメーターを使用出来ます。
(1) DIRECTORY -- A directory from which the data named by NAME should be retrieved.
NAME で名前指定されたデータを取り出すディレクトリ。
(2) MODE -- A case-insensitive string indicating the mode to be used when retrieving the information. The valid values for access-type "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the TFTP protocol [RFC-783]. The valid values for access-type "FTP" are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a decimal integer, typically 8. These correspond to the representation types "A" "E" "I" and "L n" as specified by the FTP protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid values for MODE and that "OCTET" or "IMAGE" or "LOCAL8" should be used instead. IF MODE is not specified, the default value is "NETASCII" for TFTP and "ASCII" otherwise.
情報を取り出すときに使う状態を示す、大文字・小文字を区別しない文字列。 Access-type "TFTP" で可能な値は、 "NETASCII", "OCTET", "MAIL" で、 TFTP プロトコルで規定されています。 Access-type "FTP" で有効な値は、 "ASCII", "EBCDIC", "IMAGE", "LOCALn" (ここで "n" は整数値で、典型的には 8) です。これらは FTP プロトコルで規定された 表現形 "A" "E" "I" "L n" に対応します。なお、 "BINARY" と "TENEX" は MODE では妥当な値ではなく、 "OCTET" か "IMAGE" か "LOCAL8" を代わりに使うべきです。 MODE が指定されていない場合、既定値は TFTP では "NETASCII", そうでなければ "ASCII" です。
MODE -- A transfer mode for retrieving the information, e.g. "image".
これだけの定義でした。ですから、 "BINARY", "TENEX" は実際に 使われていた値かもしれません。 ]]
The "anon-ftp" access-type is identical to the "ftp" access type, except that the user need not be asked to provide a name and password for the specified site. Instead, the ftp protocol will be used with login "anonymous" and a password that corresponds to the user's mail address.
"anon-ftp" access-type は、 "ftp" 接続型と同等ですが、 利用者は指定されたサイトの名前と合言葉を尋ねられることはありません。 代わりに、 ftp プロトコルは login "anonymous" と、 利用者のメイル・アドレスに対応する合言葉を使います。
An access-type of "local-file" indicates that the actual body is accessible as a file on the local machine. Two additional parameters are defined for this access type:
"local-file" の access-type は、実際の本文が local 機械の ファイルとして接続可能であることを示します。2つの追加のパラメーターを この接続型に定義します。
An access-type of "afs" indicates that the file is accessible via the global AFS file system.
"afs" の access-type は、ファイルが広域 AFS ファイル系から 入手可能であることを示します。、
]]
(1) NAME -- The name of the file that contains the actual body data. This parameter is mandatory for the "local-file" access-type.
実際の本文データを含むファイルの名前。このパラメーターは "local-file" access-type には必須です。
(2) SITE -- A domain specifier for a machine or set of machines that are known to have access to the data file. This optional parameter is used to describe the locality of reference for the data, that is, the site or sites at which the file is expected to be visible. Asterisks may be used for wildcard matching to a part of a domain name, such as "*.bellcore.com", to indicate a set of machines on which the data should be directly visible, while a single asterisk may be used to indicate a file that is expected to be universally available, e.g., via a global file system.
データ・ファイルへの接続があると知られている機械あるいは 機械の集合のドメイン指定子。この省略可能なパラメーターは、 データの参照の local さ、つまりファイルが可視状態にあると 思われるサイトを指定するのに使います。米印は、 "*.bellcore.com" のようにドメイン名の部分に合致するワイルドカードに使うことが出来て、 データが直接可視である機械の集合を示しますし、単一の米印は ファイルが普遍的に利用可能 (例: 広域ファイル系を通して。) であることを示すのに使うことが出来ます。
The "mail-server" access-type indicates that the actual body is available from a mail server. Two additional parameters are defined for this access-type:
"Mail-server" access-type は、実際の本文がメイル・サーバーから 入手可能であることを示します。2つの追加のパラメーターを この access-type に定義します。
(1) SERVER -- The addr-spec of the mail server from which the actual body data can be obtained. This parameter is mandatory for the "mail-server" access-type.
実際の本文データを得ることが出来るメイル・サーバーの addr-spec。このパラメーターは "mail-server" access-type には必須です。
(2) SUBJECT -- The subject that is to be used in the mail that is sent to obtain the data. Note that keying mail servers on Subject lines is NOT recommended, but such mail servers are known to exist. This is an optional parameter.
データを得る為に送信するメイルに使われる subject。 Subject 行をメイル・サーバーの鍵にするのは推奨しませんが、 そうしたメイル・サーバーが存在することが知られています。 これは省略可能なパラメーターです。
Because mail servers accept a variety of syntaxes, some of which is multiline, the full command to be sent to a mail server is not included as a parameter in the content-type header field. Instead, it is provided as the "phantom body" when the media type is "message/external-body" and the access-type is mail-server.
メイル・サーバーは複数行とか種種の構文を受け付けますから、 メイル・サーバーに送る完全な命令は content-type 頭領域のパラメーターに含めません。代わりに、媒体型が "message/external-body" で access-type が mail-server の際には「見かけの本文」を利用出来ます。
Note that MIME does not define a mail server syntax. Rather, it allows the inclusion of arbitrary mail server commands in the phantom body. Implementations must include the phantom body in the body of the message it sends to the mail server address to retrieve the relevant data.
なお、 MIME はメイル・サーバーの構文を定義しません。 むしろ、任意のメイル・サーバー命令を見かけの本文に含めることが 出来ます。実装は、見かけの本文を、 適切なデータを得る為に、メイル・サーバー・アドレスに送る メッセージの本文中に含めなければなりません。
Unlike other access-types, mail-server access is asynchronous and will happen at an unpredictable time in the future. For this reason, it is important that there be a mechanism by which the returned data can be matched up with the original "message/external-body" entity. MIME mail servers must use the same Content-ID field on the returned message that was used in the original "message/external-body" entities, to facilitate such matching.
他の access-type とは異なり、 mail-server 接続は非同期で、 将来の予期せぬ時に起こり得ます。この理由から、返送されたデータを 元の "message/external-body" 実体に対応させることが出来る方法が あることが重要になります。 MIME メイル・サーバーは、この一致確認んのため、 返送メッセージに元の "message/external-body" 実体で使われたのと同じ Content-ID 領域を使わなければなりません。
"Message/external-body" entities give rise to two important security issues:
"message/external-body" 実体は、2つの重大な安全性問題を起こします。
(1) Accessing data via a "message/external-body" reference effectively results in the message recipient performing an operation that was specified by the message originator. It is therefore possible for the message originator to trick a recipient into doing something they would not have done otherwise. For example, an originator could specify a action that attempts retrieval of material that the recipient is not authorized to obtain, causing the recipient to unwittingly violate some security policy. For this reason, user agents capable of resolving external references must always take steps to describe the action they are to take to the recipient and ask for explicit permisssion prior to performing it.
"message/external-body" 参照を通してデータに接続することは、 実質的に、メッセージ作成者が指定した処理をメッセージ受信者が行う ことになります。ですから、作成者が、受信者がそうでもなければ しないだろうことを受信者にさせることが可能です。例えば、 作成者は受信者が得る権限の無いものを得ようとして、 受信者が無意識に安全性の方針を破ることになる行動を指定する ことが出来ます。この理由から、外部参照を解決する能力のある利用者代理者は、 必ず起こそうとしている行動を受信者に説明する段階を踏んで、 行う前に明示的な許可を求めなければなりません。
The 'mail-server' access-type is particularly vulnerable, in that it causes the recipient to send a new message whose contents are specified by the original message's originator. Given the potential for abuse, any such request messages that are constructed should contain a clear indication that they were generated automatically (e.g. in a Comments: header field) in an attempt to resolve a MIME "message/external-body" reference.
'mail-server' access-type は、元のメッセージの送信者 が指定した内容の新しいメッセージを受信者が送信することになりますから、 特に脆弱です。乱用の可能性があるので、そうして組み立てられる 要求メッセージには、 MIME "message/external-body" 参照の 解決のために自動的に生成されたことの明示を (例: Comments: 頭領域中に) 含めるべきです。
(2) MIME will sometimes be used in environments that provide some guarantee of message integrity and authenticity. If present, such guarantees may apply only to the actual direct content of messages -- they may or may not apply to data accessed through MIME's "message/external-body" mechanism. In particular, it may be possible to subvert certain access mechanisms even when the messaging system itself is secure.
It should be noted that this problem exists either with or without the availabilty of MIME mechanisms. A casual reference to an FTP site containing a document in the text of a secure message brings up similar issues -- the only difference is that MIME provides for automatic retrieval of such material, and users may place unwarranted trust is such automatic retrieval mechanisms.
When the external-body mechanism is used in conjunction with the "multipart/alternative" media type it extends the functionality of "multipart/alternative" to include the case where the same entity is provided in the same format but via different accces mechanisms. When this is done the originator of the message must order the parts first in terms of preferred formats and then by preferred access mechanisms. The recipient's viewer should then evaluate the list both in terms of format and access mechanisms.
With the emerging possibility of very wide-area file systems, it becomes very hard to know in advance the set of machines where a file will and will not be accessible directly from the file system. Therefore it may make sense to provide both a file name, to be tried directly, and the name of one or more sites from which the file is known to be accessible. An implementation can try to retrieve remote files using FTP or any other protocol, using anonymous file retrieval or prompting the user for the necessary name and password. If an external body is accessible via multiple mechanisms, the sender may include multiple entities of type "message/external-body" within the body parts of an enclosing "multipart/alternative" entity.
However, the external-body mechanism is not intended to be limited to file retrieval, as shown by the mail-server access-type. Beyond this, one can imagine, for example, using a video server for external references to video clips.
The embedded message header fields which appear in the body of the "message/external-body" data must be used to declare the media type of the external body if it is anything other than plain US-ASCII text, since the external body does not have a header section to declare its type. Similarly, any Content-transfer-encoding other than "7bit" must also be declared here. Thus a complete "message/external-body" message, referring to an object in PostScript format, might look like this:
From: Whomever To: Someone Date: Whenever Subject: whatever MIME-Version: 1.0 Message-ID: <id1@host.com> Content-Type: multipart/alternative; boundary=42 Content-ID: <id001@guppylake.bellcore.com> --42 Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; mode="image"; access-type=ANON-FTP; directory="pub"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> --42 Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> --42 Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> get RFC-MIME.DOC --42--
Note that in the above examples, the default Content-transfer- encoding of "7bit" is assumed for the external postscript data.
Like the "message/partial" type, the "message/external-body" media type is intended to be transparent, that is, to convey the data type in the external body rather than to convey a message with a body of that type. Thus the headers on the outer and inner parts must be merged using the same rules as for "message/partial". In particular, this means that the Content-type and Subject fields are overridden, but the From field is preserved.
Note that since the external bodies are not transported along with the external body reference, they need not conform to transport limitations that apply to the reference itself. In particular, Internet mail transports may impose 7bit and line length limits, but these do not automatically apply to binary external body references. Thus a Content-Transfer-Encoding is not generally necessary, though it is permitted.
Note that the body of a message of type "message/external-body" is governed by the basic syntax for an RFC 822 message. In particular, anything before the first consecutive pair of CRLFs is header information, while anything after it is body information, which is ignored for most access-types.
The formal grammar for content-type header fields for data of type message is given by:
message-type := "message" "/" message-subtype
message-subtype := "rfc822" / "partial" 2#3partial-param / "external-body" 1*external-param / extension-token
partial-param := (";" "id" "=" value) / (";" "number" "=" 1*DIGIT) / (";" "total" "=" 1*DIGIT) ; id & number required; total required for last part
external-param := (";" "access-type" "=" atype) / (";" "expiration" "=" date-time) ; Note that date-time is quoted / (";" "size" "=" 1*DIGIT) / (";" "permission" "=" ("read" / "read-write")) ; Permission is case-insensitive / (";" "name" "=" value) / (";" "site" "=" value) / (";" "dir" "=" value) / (";" "mode" "=" value) / (";" "server" "=" value) / (";" "subject" "=" value) ; access-type required;others required based on access-type
atype := "ftp" / "anon-ftp" / "tftp" / "local-file" / "afs" / "mail-server" / extension-token ; Case-insensitive
]]
[3] にせ本体の頭として X-Last-Modified: 19920514010000Z (1992 May 14 01:00:00 GMT) なんてのが入っているのを見つけました。 (名無しさん)
[4] MIME の External-Body で本文と添付ファイルを分離保存 http://sonic64.com/2005-08-29.html#2005-08-29-1
偽頭部にファイル名を記述する方法が無いとして
X-Original-File-Name
欄なるものを導入しているが、
Content-*
以外の名前の欄は無効
RFC 2046 だから意味が無い。あと、
Content-Disposition
filename
がちゃんとある。
あと、ここに出ている例は Content-ID
が不正。
[5] RFC 4483 - A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages ( ( 版)) http://tools.ietf.org/html/rfc4483
Implementations should support Content-Type: message/external-body extensions for request bodies for HTTP POST that would create LDP-NRs. This content-type requires a complete Content-Type header that includes the location of the external body, e.g Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\", as defined in [RFC2017].
[25] Welcome to Netscape Navigator 3.0, , https://web.archive.org/web/20020630200918/http://wp.netscape.com/eng/mozilla/3.0/relnotes/windows-3.0.html#MIME
message/partial
も参照。