1 |
IETF URI Working Group |
2 |
Internet-Draft |
3 |
draft-ietf-uri-url-mailserver-00.txt |
4 |
Expires July 23, 1995 |
5 |
|
6 |
|
7 |
Mailserver URL Specification |
8 |
|
9 |
Status of This Memo |
10 |
|
11 |
This document is an Internet-Draft. Internet-Drafts are working |
12 |
documents of the Internet Engineering Task Force (IETF), its |
13 |
areas, and its working groups. Note that other groups may also |
14 |
distribute working documents as Internet-Drafts. |
15 |
|
16 |
Internet-Drafts are draft documents valid for a maximum of six |
17 |
months and may be updated, replaced, or obsoleted by other |
18 |
documents at any time. It is inappropriate to use Internet- |
19 |
Drafts as reference material or to cite them other than as |
20 |
``work in progress.'' |
21 |
|
22 |
To learn the current status of any Internet-Draft, please check |
23 |
the ``1id-abstracts.txt'' listing contained in the Internet- |
24 |
Drafts Shadow Directories on ftp.is.co.za (Africa), |
25 |
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), |
26 |
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). |
27 |
|
28 |
Abstract |
29 |
|
30 |
A new URL scheme, "mailserver", is defined. It allows mail client |
31 |
software to create RFC822 mail messages from a URL. |
32 |
|
33 |
Description |
34 |
|
35 |
In the URL specification, RFC1738, the "mailto" scheme is defined and is |
36 |
described as: |
37 |
|
38 |
Unlike many URLs, the mailto scheme does not represent a data |
39 |
object to be accessed directly; there is no sense in which it |
40 |
designates an object. |
41 |
|
42 |
However, there are many resources on the Internet that can only be |
43 |
accessed by mail that cannot be described by the mailto scheme. To |
44 |
access such an object, the mail message must have a specified subject |
45 |
and/or content. For instance, many mail response servers will return a |
46 |
file if you send a mail message with the proper request. |
47 |
|
48 |
The "mailserver" URL has the form: |
49 |
|
50 |
mailserver:<rfc822-addr-spec>/*[<header>/]/<body> |
51 |
|
52 |
Client software would prepare a mail message with the given headers and |
53 |
the <body> text as the body of the message. |
54 |
|
55 |
Thus, the "mailto" scheme will be used to give the mailing address of a |
56 |
person or of a mailserver that requires no subject or message body; the |
57 |
"mailserver" scheme is used to give a template that will cause the |
58 |
specified resource to be returned. |
59 |
|
60 |
Headers are given in RFC822 format, and it is likely (and probably |
61 |
preferable) that only a "Subject:" header be included. Headers are given |
62 |
without spaces after them, such as "Subject:current-issue". |
63 |
|
64 |
The body text may span more than one line. Any "/" character in the body |
65 |
should be interpreted by the mail client as a CRLF sequence when |
66 |
translating a URL to a mail message. |
67 |
|
68 |
Examples |
69 |
|
70 |
A URL for a mail response system that requires the name of the file in |
71 |
the subject might be: |
72 |
|
73 |
<mailserver:infobot@kwf.com/Subject:current-issue//> |
74 |
|
75 |
A mail response system that requires a "send" request in the body might |
76 |
have a URL that looks like: |
77 |
|
78 |
<mailserver:infobot@kwf.com//send%20current-issue> |
79 |
|
80 |
A similar URL could have two lines with different "send" requests: |
81 |
|
82 |
<mailserver:infobot@kwf.com//send%20current-issue/send%20index> |
83 |
|
84 |
The "mailserver" scheme would also help people get another type of |
85 |
Internet resource, namely mailing lists. For example: |
86 |
|
87 |
<mailserver:majordomo@kwf.com//subscribe%20bamboo-l> |
88 |
|
89 |
Encoding |
90 |
|
91 |
RFC1738 requires that many characters in URLs be encoded. This affects |
92 |
the mailserver scheme for some common characters that might appear in |
93 |
subjects or message contents. Two such characters are space (" ", ASCII |
94 |
hex 20) and forward slash ("/", ASCII hex 2F). Note the examples |
95 |
above that use "%20" for space in the message body. Note further that an |
96 |
unencoded forward slash in the body area (after the "//") is to be |
97 |
translated by the mail client to CRLF. |
98 |
|
99 |
People creating mailserver URLs must be careful to encode any reserved |
100 |
characters that are used in the URLs so that properly-written URL |
101 |
interpreters can read them. Also, client software that reads URLs must |
102 |
be careful to decode strings before creating the mail message so that |
103 |
the mail messages appear in a form that the recipient will understand. |
104 |
These strings should be decoded before showing the user the mesage. |
105 |
|
106 |
Specifying Headers |
107 |
|
108 |
A mailserver URL can include headers for the client software to add to |
109 |
the message. Each header is in the form: |
110 |
|
111 |
<header-name>:<text>/ |
112 |
|
113 |
Thus, a URL with a "Subject:" header, a "X-magic" header, and a body |
114 |
might look like: |
115 |
|
116 |
<mailserver:files@kwf.com/Subject:archive/X-magic:18rtg//mail%20arch17> |
117 |
|
118 |
See the "Security" section below for important considerations for using |
119 |
headers. |
120 |
|
121 |
Additional BNF for RFC1738 |
122 |
|
123 |
mailserverurl = "mailserver:" encoded822addr "/" *[header "/"] |
124 |
"/" body |
125 |
body = [body_line] *["/" body_line] |
126 |
body_line = *[uchar] |
127 |
header = encoded822header ":" header_text |
128 |
encoded822header = 1*xchar ; further defined in RFC822 |
129 |
header_text = *[uchar] |
130 |
|
131 |
Security |
132 |
|
133 |
The mailserver scheme is intended to send a message from one user to |
134 |
another, and thus can introduce many security concerns. Mail messages |
135 |
can be logged at the originating site, the recipient site, and |
136 |
intermediary sites along the delivery path. If the messages are not |
137 |
encoded, they can also be read at any of those sites. |
138 |
|
139 |
A mailserver URL gives a template for a message that can be sent by mail |
140 |
client software. The contents of that template may be opaque or |
141 |
difficult to read by the user at the time of specifying the URL. Thus, a |
142 |
mail client should never send a message based on a mailserver URL |
143 |
without first showing the user the full message that will be sent |
144 |
(including all headers, including those specified in the URL), fully |
145 |
decoded, and asking the user for approval to send the message. Examples |
146 |
of problems with sending unapproved mail include: |
147 |
- mail that breaks laws upon delivery, such as making illegal threats |
148 |
- mail that identifies the sender as someone interested in breaking laws |
149 |
- mail that identifies the sender to an unwanted third party |
150 |
- mail that goes to an unwanted party, such as through a "cc:" or "bcc:" |
151 |
header |
152 |
- mail that causes a financial charge to be incurred on the sender |
153 |
- mail that causes an action on the recipient machine that causes damage |
154 |
that might be attributed to the sender |
155 |
|
156 |
If a mailserver URL specifies headers, these headers can cause security |
157 |
problems, such as identifying the sender to a malicious third party. |
158 |
Further, headers other than "Subject:" can cause undefined actions in |
159 |
some mail programs that may compromise security. Security-conscious mail |
160 |
clients should scrutinize the headers and their contents before |
161 |
including them in mail messages; some clients might even choose to |
162 |
ignore some or all of the headers other than "Subject:" in a URL. |
163 |
|
164 |
Author contact information: |
165 |
|
166 |
Paul E. Hoffman |
167 |
Proper Publishing |
168 |
127 Segre Place |
169 |
Santa Cruz, CA 95060 USA |
170 |
Tel: 408-426-6222 |
171 |
phoffman@proper.com |
172 |
|
173 |
|