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
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.
版权所有（C）互联网协会（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）的格式。它是替代RFC 1738“统一资源定位器”和RFC 1808“相对统一资源定位器”的一套文档之一。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.
MailToURL方案用于指定个人或服务的Internet邮寄地址。最简单的形式是，mailto URL包含一个Internet邮件地址。
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
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.
“邮箱”如RFC 822[RFC822]中所述。这意味着它由零个或多个逗号分隔的邮件地址组成，可能包括“短语”和“注释”组件。请注意，“to”中的所有URL保留字符都必须进行编码：特别是括号、逗号和百分号（“%”），它们通常出现在“mailbox”语法中。
"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是消息的主体。“正文”hname应包含消息的第一个文本/纯正文部分的内容。MailToURL主要用于生成实际上是自动处理内容的短文本消息（例如邮件列表的“订阅”消息），而不是一般的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必须使用“&；”而不是“&”。
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
邮寄地址：addr1%2C%20addr2
is equivalent to
相当于
mailto:?to=addr1%2C%20addr2
邮件收件人：？收件人=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]中的定义），但“正文”hname的任何部分都不允许使用MIME编码字。
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指定“internet资源”，即地址中指定的邮箱。当提供额外的头时，指定的资源是相同的地址，但具有用于访问资源的额外配置文件。虽然有些Internet资源只能通过电子邮件访问，但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会导致客户端软件和运行交互式服务器的主机之间的即时交互。“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.
如果任何邮件头被认为是危险的，则解释邮件URL的用户代理应选择不创建邮件；它还可以选择仅使用URL中给定的标题子集创建消息。只有主题、关键字和正文标题被认为是安全和有用的。
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的解析程序理解的内容超过“主题”和“正文”标题。将mailto URL解析为邮件消息的客户端应该能够使用“主题”和“正文”标题正确创建符合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".
RFC1738要求对URL中的许多字符进行编码。这会影响地址、标题或邮件内容中可能出现的某些常见字符的mailto方案。一个这样的字符是空格（“，ASCII十六进制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
创建mailto URL的人必须小心对URL中使用的任何保留字符进行编码，以便正确编写的URL解释器能够读取它们。此外，读取URL的客户端软件在创建邮件消息之前必须仔细解码字符串，以便
that the mail messages appear in a form that the recipient will understand. These strings should be decoded before showing the user the message.
邮件信息以收件人能够理解的形式出现。在向用户显示消息之前，应先对这些字符串进行解码。
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.
MailToURL方案的局限性在于它不提供变量替换。因此，必须包含用户电子邮件地址的消息正文不能使用mailto URL进行编码。此限制还阻止使用公钥和其他此类变量信息签名的mailto URL。
URLs for an ordinary individual mailing address:
普通个人邮寄地址的URL：
<mailto:chris@example.com>
<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>
<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>
<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可能有两行不同的“发送”请求（在本例中为“发送当前问题”，在下一行为“发送索引”。）
<mailto:infobot@example.com?body=send%20current-
issue%0D%0Asend%20index>
<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:
MailToURL的一个有趣用法是在浏览邮件存档时使用。每个浏览过的邮件可能包含一个mailto URL，如：
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
<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>
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
A URL for a single user which includes a CC of another user:
单个用户的URL，包括另一个用户的CC：
<mailto:joe@example.com?cc=bob@example.com&body=hello>
<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>
<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:
注意上面使用的“&”保留字符。以下示例两次使用“？”是不正确的：
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
<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规范中。在这个URL方案中，它们是保留字符这一事实并不是问题：这些字符可能出现在mailto URL中，它们可能不会以未编码的形式出现。在某些情况下，必须使用标准URL编码机制（“%”后跟两位十六进制数）。
To indicate the address "gorby%kremvax@example.com" one would do:
表示地址“gorby%kremvax@example.com“我们可以这样做：
<mailto:gorby%25kremvax@example.com>
<mailto:gorby%25kremvax@example.com>
To indicate the address "unlikely?address@example.com", and include another header, one would do:
表示地址“不太可能？address@example.com，并包含另一个标题，可以执行以下操作：
<mailto:unlikely%3Faddress@example.com?blat=foop>
<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中保留了“&”（和号）字符，必须用“&；”替换。因此，具有内部符号的复杂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:？到=joe@xyz.com&；cc=bob@xyz.com&；body=hello“>邮件收件人：？收件人=joe@xyz.com&；抄送=bob@xyz.com&；body=hello</a>向乔和鲍勃发送问候信息。
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.
MailToURL为邮件客户端软件发送的邮件提供模板。在指定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版本，内容-*）很可能不合适，与路由相关的头（From、Bcc、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“发件人”地址已设置且正确。
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，编辑，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RFC1808]菲尔丁，R.，“相对统一资源定位器”，RFC18081995年6月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME第三部分：非ASCII文本的消息头扩展”，RFC 20471996年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规范（不是完整的邮箱）。然而，所需的使用和实现导致了包含更多标题字段的扩展语法的开发。
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
美国加利福尼亚州圣克鲁斯塞格雷广场127号保罗·E·霍夫曼互联网邮件联盟，邮编95060
EMail: phoffman@imc.org
EMail: phoffman@imc.org
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94304 USA
美国加利福尼亚州帕洛阿尔托郊狼山路3333号拉里·马斯特施乐公司，邮编94304
EMail: masinter@parc.xerox.com
EMail: masinter@parc.xerox.com
Jamie Zawinski Netscape Communications Corp. 501 East Middlefield Road Mountain View, CA 94043 USA
杰米·扎温斯基网景通信公司，美国加利福尼亚州东米德菲尔德路501号山景城，邮编94043
EMail: jwz@netscape.com
EMail: jwz@netscape.com
D. Full Copyright Statement
D.完整的版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。