[要約] RFC 2368は、mailto URLスキームに関する仕様を定めたものであり、電子メールアドレスを含むリンクを作成するための方法を提供しています。目的は、Webページやアプリケーションでメール送信を簡単にすることです。
Network Working Group P. Hoffman
Request for Comments: 2368 Internet Mail Consortium
Updates: 1738, 1808 L. Masinter
Category: Standards Track Xerox Corporation
J. Zawinski
Netscape Communications
July 1998
The mailto URL scheme
mailto URLスキーム
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', and RFC 1808, 'Relative Uniform Resource Locators'. The syntax of 'mailto' URLs from RFC 1738 is extended to allow creation of more RFC 822 messages by allowing the URL to express additional header and body fields.
このドキュメントでは、電子メールアドレスを指定するためのURL（Uniform Resource Locator）の形式を定義しています。これは、RFC 1738の「Uniform Resource Locators」、およびRFC 1808の「Relative Uniform Resource Locators」に代わる一連のドキュメントの1つです。 RFC 1738の「mailto」URLの構文が拡張され、URLが追加のヘッダーフィールドと本文フィールドを表現できるようにすることで、より多くのRFC 822メッセージを作成できるようになりました。
The mailto URL scheme is used to designate the Internet mailing address of an individual or service. In its simplest form, a mailto URL contains an Internet mail address.
mailto URLスキームは、個人またはサービスのインターネットメールアドレスを指定するために使用されます。最も単純な形式では、mailto URLにはインターネットメールアドレスが含まれます。
For greater functionality, because interaction with some resources may require message headers or message bodies to be specified as well as the mail address, the mailto URL scheme is extended to allow setting mail header fields and the message body.
機能性を高めるために、一部のリソースとのやり取りでは、メッセージヘッダーまたはメッセージ本文とメールアドレスを指定する必要があるため、mailto URLスキームが拡張され、メールヘッダーフィールドとメッセージ本文を設定できるようになりました。
Following the syntax conventions of RFC 1738 [RFC1738], a "mailto" URL has the form:
RFC 1738 [RFC1738]の構文規則に従って、「mailto」URLの形式は次のとおりです。
mailtoURL = "mailto:" [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
"#mailbox" is as specified in RFC 822 [RFC822]. This means that it consists of zero or more comma-separated mail addresses, possibly including "phrase" and "comment" components. Note that all URL reserved characters in "to" must be encoded: in particular, parentheses, commas, and the percent sign ("%"), which commonly occur in the "mailbox" syntax.
「#mailbox」はRFC 822 [RFC822]で指定されているとおりです。つまり、0個以上のカンマ区切りのメールアドレスで構成され、「フレーズ」コンポーネントと「コメント」コンポーネントが含まれている可能性があります。 「to」内のすべてのURL予約文字はエンコードする必要があることに注意してください。特に、括弧、コンマ、パーセント記号（「％」）は、「メールボックス」構文で一般的に発生します。
"hname" and "hvalue" are encodings of an RFC 822 header name and value, respectively. As with "to", all URL reserved characters must be encoded.
「hname」と「hvalue」は、それぞれRFC 822ヘッダーの名前と値のエンコーディングです。 「to」と同様に、すべてのURL予約文字をエンコードする必要があります。
The special hname "body" indicates that the associated hvalue is the body of the message. The "body" hname should contain the content for the first text/plain body part of the message. The mailto URL is primarily intended for generation of short text messages that are actually the content of automatic processing (such as "subscribe" messages for mailing lists), not general MIME bodies.
特別なhname "body"は、関連付けられたhvalueがメッセージの本文であることを示します。 "body" hnameには、メッセージの最初のtext / plain body部分のコンテンツを含める必要があります。 mailto URLは主に、一般的なMIME本文ではなく、実際には自動処理の内容（メーリングリストの「購読」メッセージなど）である短いテキストメッセージの生成を目的としています。
Within mailto URLs, the characters "?", "=", "&" are reserved.
mailto URLでは、「？」、「=」、「＆」の文字が予約されています。
Because the "&" (ampersand) character is reserved in HTML, any mailto URL which contains an ampersand must be spelled differently in HTML than in other contexts. A mailto URL which appears in an HTML document must use "&" instead of "&".
「＆」（アンパサンド）文字はHTMLで予約されているため、アンパサンドを含むmailto URLのスペルは、HTMLでは他のコンテキストとは異なるものにする必要があります。 HTMLドキュメントに表示されるmailto URLには「＆amp;」を使用する必要がありますの代わりに "＆"。
Also note that it is legal to specify both "to" and an "hname" whose value is "to". That is,
また、 "to"と、値が "to"である "hname"の両方を指定することは合法であることにも注意してください。あれは、
mailto:addr1%2C%20addr2
mailto：addr1％2C％20addr2
is equivalent to
に相当
mailto:?to=addr1%2C%20addr2
mailto：？to = addr1％2C％20addr2
is equivalent to
に相当
mailto:addr1?to=addr2
mailto：addr1？to = addr2
8-bit characters in mailto URLs are forbidden. MIME encoded words (as defined in [RFC2047]) are permitted in header values, but not for any part of a "body" hname.
mailto URLでの8ビット文字は禁止されています。 MIMEエンコードされた単語（[RFC2047]で定義）は、ヘッダー値で許可されていますが、「body」hnameのどの部分でも許可されていません。
A mailto URL designates an "internet resource", which is the mailbox specified in the address. When additional headers are supplied, the resource designated is the same address, but with an additional profile for accessing the resource. While there are Internet resources that can only be accessed via electronic mail, the mailto URL is not intended as a way of retrieving such objects automatically.
mailto URLは、アドレスで指定されたメールボックスである「インターネットリソース」を指定します。追加のヘッダーが提供されると、指定されたリソースは同じアドレスですが、リソースにアクセスするための追加のプロファイルが追加されます。電子メールを介してのみアクセスできるインターネットリソースがありますが、mailto URLは、そのようなオブジェクトを自動的に取得する方法としては意図されていません。
In current practice, resolving URLs such as those in the "http" scheme causes an immediate interaction between client software and a host running an interactive server. The "mailto" URL has unusual semantics because resolving such a URL does not cause an immediate interaction. Instead, the client creates a message to the designated address with the various header fields set as default. The user can edit the message, send this message unedited, or choose not to send the message. The operation of how any URL scheme is resolved is not mandated by the URL specifications.
現在のやり方では、 "http"スキームのURLなどのURLを解決すると、クライアントソフトウェアとインタラクティブサーバーを実行しているホストの間で即座に対話が行われます。 「mailto」URLは、そのようなURLを解決しても即時の対話が発生しないため、異常なセマンティクスを持っています。代わりに、クライアントは、さまざまなヘッダーフィールドをデフォルトとして設定して、指定されたアドレスにメッセージを作成します。ユーザーはメッセージを編集するか、このメッセージを編集せずに送信するか、メッセージを送信しないことを選択できます。 URLスキームの解決方法の操作は、URL仕様では必須ではありません。
The user agent interpreting a mailto URL SHOULD choose not to create a message if any of the headers are considered dangerous; it may also choose to create a message with only a subset of the headers given in the URL. Only the Subject, Keywords, and Body headers are believed to be both safe and useful.
mailto URLを解釈するユーザーエージェントは、いずれかのヘッダーが危険であると見なされる場合、メッセージを作成しないことを選択する必要があります。また、URLで指定されたヘッダーのサブセットのみを使用してメッセージを作成することもできます。安全で有用であると考えられているのは、Subject、Keywords、Bodyヘッダーのみです。
The creator of a mailto URL cannot expect the resolver of a URL to understand more than the "subject" and "body" headers. Clients that resolve mailto URLs into mail messages should be able to correctly create RFC 822-compliant mail messages using the "subject" and "body" headers.
mailto URLの作成者は、URLのリゾルバーが「subject」および「body」ヘッダー以外を理解することを期待できません。 mailto URLをメールメッセージに解決するクライアントは、「subject」および「body」ヘッダーを使用してRFC 822準拠のメールメッセージを正しく作成できる必要があります。
RFC 1738 requires that many characters in URLs be encoded. This affects the mailto scheme for some common characters that might appear in addresses, headers or message contents. One such character is space (" ", ASCII hex 20). Note the examples above that use "%20" for space in the message body. Also note that line breaks in the body of a message MUST be encoded with "%0D%0A".
RFC 1738では、URLの多くの文字をエンコードする必要があります。これは、アドレス、ヘッダー、またはメッセージの内容に表示される可能性があるいくつかの一般的な文字のmailtoスキームに影響します。そのような文字の1つはスペース（ ""、ASCII 16進数20）です。上記の例では、メッセージ本文のスペースに「％20」を使用しています。また、メッセージ本文の改行は「％0D％0A」でエンコードする必要があることに注意してください。
People creating mailto URLs must be careful to encode any reserved characters that are used in the URLs so that properly-written URL interpreters can read them. Also, client software that reads URLs must be careful to decode strings before creating the mail message so that the mail messages appear in a form that the recipient will understand. These strings should be decoded before showing the user the message.
mailto URLを作成する人は、適切に作成されたURLインタープリターがそれらを読み取れるように、URLで使用される予約文字をエンコードするように注意する必要があります。また、URLを読み取るクライアントソフトウェアは、メールメッセージが受信者が理解できる形式で表示されるように、メールメッセージを作成する前に文字列をデコードするように注意する必要があります。これらの文字列は、ユーザーにメッセージを表示する前にデコードする必要があります。
The mailto URL scheme is limited in that it does not provide for substitution of variables. Thus, a message body that must include a user's email address can not be encoded using the mailto URL. This limitation also prevents mailto URLs that are signed with public keys and other such variable information.
mailto URLスキームは、変数の置換を提供しないという点で制限されています。したがって、ユーザーの電子メールアドレスを含める必要があるメッセージ本文は、mailto URLを使用してエンコードできません。この制限により、公開鍵などの可変情報で署名されたmailto URLも防止されます。
URLs for an ordinary individual mailing address:
通常の個人のメールアドレスのURL：
<mailto:chris@example.com>
A URL for a mail response system that requires the name of the file in the subject:
件名にファイルの名前が必要なメール応答システムのURL：
<mailto:infobot@example.com?subject=current-issue>
A mail response system that requires a "send" request in the body:
本文に「送信」リクエストが必要なメール応答システム：
<mailto:infobot@example.com?body=send%20current-issue>
A similar URL could have two lines with different "send" requests (in this case, "send current-issue" and, on the next line, "send index".)
同様のURLには、「送信」リクエストが異なる2つの行が含まれる可能性があります（この場合、「現在の問題を送信」、次の行に「インデックスを送信」）。
<mailto:infobot@example.com?body=send%20current-
issue%0D%0Asend%20index>
An interesting use of your mailto URL is when browsing archives of messages. Each browsed message might contain a mailto URL like:
mailto URLの興味深い使い方は、メッセージのアーカイブを閲覧するときです。閲覧された各メッセージには、次のようなmailto URLが含まれる場合があります。
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
A request to subscribe to a mailing list:
メーリングリストを購読するリクエスト：
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
A URL for a single user which includes a CC of another user:
別のユーザーのCCを含む単一のユーザーのURL：
<mailto:joe@example.com?cc=bob@example.com&body=hello>
Another way of expressing the same thing:
同じことを表現する別の方法：
<mailto:?to=joe@example.com&cc=bob@example.com&body=hello>
Note the use of the "&" reserved character, above. The following example, by using "?" twice, is incorrect:
上記の「＆」予約文字の使用に注意してください。次の例では、「？」を使用しています。 2回、間違っています：
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
According to RFC 822, the characters "?", "&", and even "%" may occur in addr-specs. The fact that they are reserved characters in this URL scheme is not a problem: those characters may appear in mailto URLs, they just may not appear in unencoded form. The standard URL encoding mechanisms ("%" followed by a two-digit hex number) must be used in certain cases.
RFC 822によれば、文字「？」、「＆」、さらには「％」でさえaddr-specsで発生する可能性があります。このURLスキームで予約文字であることは問題ではありません。これらの文字はmailto URLに表示される場合があり、エンコードされていない形式では表示されない場合があります。場合によっては、標準のURLエンコードメカニズム（ "％"の後に2桁の16進数が続く）を使用する必要があります。
To indicate the address "gorby%kremvax@example.com" one would do:
「gorby%kremvax@example.com」というアドレスを示すには、次のようにします。
<mailto:gorby%25kremvax@example.com>
To indicate the address "unlikely?address@example.com", and include another header, one would do:
「unlikely?address@example.com」というアドレスを示し、別のヘッダーを含めるには、次のようにします。
<mailto:unlikely%3Faddress@example.com?blat=foop>
As described above, the "&" (ampersand) character is reserved in HTML and must be replacded with "&". Thus, a complex URL that has internal ampersands might look like:
上記のように、「＆」（アンパサンド）文字はHTMLで予約されており、「＆amp;」に置き換える必要があります。したがって、内部にアンパサンドがある複雑なURLは次のようになります。
Click <a href="mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello"> mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello</a> to send a greeting message to <i>Joe and Bob</i>.
<a href="mailto:?to=joe@xyz.com& amp;cc=bob@xyz.com& amp;body=hello"> mailto：？to=joe@xyz.com& amp; cc = bob @ xyzをクリックします。 com＆amp; body = hello </a>をクリックして、<i> Joe and Bob </ i>に挨拶メッセージを送信します。
The mailto scheme can be used to send a message from one user to another, and thus can introduce many security concerns. Mail messages can be logged at the originating site, the recipient site, and intermediary sites along the delivery path. If the messages are not encoded, they can also be read at any of those sites.
mailtoスキームは、あるユーザーから別のユーザーにメッセージを送信するために使用できるため、多くのセキュリティ上の問題を引き起こす可能性があります。メールメッセージは、配信パスに沿って、送信元サイト、受信者サイト、および中間サイトでログに記録できます。メッセージがエンコードされていない場合、それらのサイトのいずれかで読み取ることもできます。
A mailto URL gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URL. Thus, a mail client should never send a message based on a mailto URL without first showing the user the full message that will be sent (including all headers that were specified by the mailto URL), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client should also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a mailto URL.
mailto URLは、メールクライアントソフトウェアが送信できるメッセージのテンプレートを提供します。そのテンプレートの内容は、URLを指定するときに、ユーザーにとって不透明または読みにくい場合があります。したがって、メールクライアントは、送信される完全なメッセージ（mailto URLで指定されたすべてのヘッダーを含む）を最初にユーザーに表示し、完全にデコードして、ユーザーに承認を求めることなく、mailto URLに基づくメッセージを送信してはなりません。メッセージを電子メールとして送信します。ユーザーがこれがmailto URLの結果であることをユーザーが認識していない場合があるため、メールクライアントはユーザーが電子メールメッセージを送信しようとしていることも明確にする必要があります。
A mail client should never send anything without complete disclosure to the user of what is will be sent; it should disclose not only the message destination, but also any headers. Unrecognized headers, or headers with values inconsistent with those the mail client would normally send should be especially suspect. MIME headers (MIME-Version, Content-*) are most likely inappropriate, as are those relating to routing (From, Bcc, Apparently-To, etc.)
メールクライアントは、何が送信されるかをユーザーに完全に開示せずに、何も送信しないでください。メッセージの宛先だけでなく、ヘッダーも開示する必要があります。認識されないヘッダー、またはメールクライアントが通常送信するヘッダーと一致しない値を持つヘッダーは、特に疑わしいはずです。 MIMEヘッダー（MIME-Version、Content- *）は、ルーティングに関連するもの（From、Bcc、Apparently-Toなど）と同様、不適切である可能性が高い
Note that some headers are inherently unsafe to include in a message generated from a URL. For example, headers such as "From:", "Bcc:", and so on, should never be interpreted from a URL. In general, the fewer headers interpreted from the URL, the less likely it is that a sending agent will create an unsafe message.
一部のヘッダーは、URLから生成されたメッセージに含めるのが本質的に安全でないことに注意してください。たとえば、「From：」、「Bcc：」などのヘッダーは、URLから解釈されるべきではありません。一般に、URLから解釈されるヘッダーが少ないほど、送信エージェントが安全でないメッセージを作成する可能性は低くなります。
Examples of problems with sending unapproved mail include:
未承認のメールの送信に関する問題の例は次のとおりです。
* mail that breaks laws upon delivery, such as making illegal threats;
* 違法な脅迫など、配達時に法律に違反するメール。
* mail that identifies the sender as someone interested in breaking laws;
* 送信者が法律違反に興味のある人物であることを示すメール。
* mail that identifies the sender to an unwanted third party;
* 不要な第三者への送信者を特定するメール。
* mail that causes a financial charge to be incurred on the sender;
* 送信者に金銭的費用が発生するメール。
* mail that causes an action on the recipient machine that causes damage that might be attributed to the sender.
* 受信者のマシンでアクションを引き起こし、送信者に起因する可能性のある損傷を引き起こすメール。
Programs that interpret mailto URLs should ensure that the SMTP "From" address is set and correct.
mailto URLを解釈するプログラムは、SMTPの "From"アドレスが設定され、正しいことを確認する必要があります。
This document changes the definition of the mailto: URI scheme; any registry of URI schemes should refer to this document rather than its predecessor, RFC 1738.
このドキュメントは、mailto：URIスキームの定義を変更します。 URIスキームのレジストリは、その前身であるRFC 1738ではなく、このドキュメントを参照する必要があります。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。、およびM. McCahill、編集者、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RFC1808]フィールディング、R。、「Relative Uniform Resource Locators」、RFC 1808、1995年6月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047] Moore、K。、「MIME Part Three：Message Header Extensions for Non-ASCII Text」、RFC 2047、1996年11月。
A. Change from RFC 1738
A. RFC 1738からの変更
RFC 1738 defined only a simple 'mailto' with no headers, just an addr-spec (not a full mailbox.) However, required usage and implementation has led to the development of an extended syntax that included more header fields.
RFC 1738は、ヘッダーのない単純な 'mailto'のみを定義し、addr-spec（メールボックス全体ではない）のみを定義しました。ただし、必要な使用法と実装により、より多くのヘッダーフィールドを含む拡張構文が開発されました。
B. Acknowledgments
B.謝辞
This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the acknowledgments from those specifications still applies.
このドキュメントは、RFC 1738およびRFC 1808 [RFC1808]から派生しました。これらの仕様からの承認は引き続き適用されます。
The following people contributed to this memo or had and discussed similar ideas for mailto.
以下の人々はこのメモに貢献したか、mailtoについて同様のアイデアを持っていて議論しました。
Harald Alvestrand Bryan Costales Steve Dorner Al Gilman Mark Joseph Laurence Lundblade Keith Moore Jacob Palme Michael Patton
ハラルドアルベストランドブライアンコスタレススティーブドーナーアルギルマンマークジョセフローレンスルンドブレードキースムーアジェイコブパルメマイケルパットン
C. Author Contact Information
C.著者の連絡先情報
Paul E. Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
Paul E. Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz、CA 95060 USA
EMail: phoffman@imc.org
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94304 USA
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto、CA 94304 USA
EMail: masinter@parc.xerox.com
Jamie Zawinski Netscape Communications Corp. 501 East Middlefield Road Mountain View, CA 94043 USA
Jamie Zawinski Netscape Communications Corp. 501 East Middlefield Road Mountain View、CA 94043 USA
EMail: jwz@netscape.com
D. Full Copyright Statement
D.完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。 、ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。