2004/id/draft-ietf-uri-url-mailserver-01.txt


IETF URI Working Group
Internet-Draft
draft-ietf-uri-url-mailserver-01.txt
Expires August 8, 1995

                       Mailserver URL Specification

Status of This Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

A new URL scheme, "mailserver", is defined. It allows mail client
software to create RFC822 mail messages from a URL.

Description

In the URL specification, RFC1738, the "mailto" scheme is defined and is
described as:

     Unlike many URLs, the mailto scheme does not represent a data
     object to be accessed directly; there is no sense in which it
     designates an object.

However, there are many resources on the Internet that can only be
accessed by mail that cannot be described by the mailto scheme. To
access such an object, the mail message must have a specified subject
and/or content. For instance, many mail response servers will return a
file if you send a mail message with the proper request.

The "mailserver" URL has the form:

     mailserver:<rfc822-addr-spec>/<subject>/<body>

Client software would prepare a mail message with the given <subject>
text as the subject header field and the <body> text as the body of the
message. <subject> and <body> may have zero length.

Thus, the "mailto" scheme will be used to give the mailing address of a
person or of a mailserver that requires no subject or message body; the
"mailserver" scheme is used to give a template that will cause the
specified resource to be returned.

The body text may span more than one line. Any "/" character in the body
should be interpreted by the mail client as a CRLF sequence when
translating a URL to a mail message.

Examples

A URL for a mail response system that requires the name of the file in
the subject might be:

<mailserver:infobot@kwf.com/current-issue/>

A mail response system that requires a "send" request in the body might
have a URL that looks like:

<mailserver:infobot@kwf.com//send%20current-issue>

A similar URL could have two lines with different "send" requests:

<mailserver:infobot@kwf.com//send%20current-issue/send%20index>

The "mailserver" scheme would also help people get another type of
Internet resource, namely mailing lists. For example:

<mailserver:majordomo@kwf.com//subscribe%20bamboo-l>

Encoding

RFC1738 requires that many characters in URLs be encoded. This affects
the mailserver scheme for some common characters that might appear in
subjects or message contents. Two such characters are space (" ", ASCII
hex 20) and forward slash ("/", ASCII hex 2F). Note the examples
above that use "%20" for space in the message body. Note further that an
unencoded forward slash in the body area is to be translated by the mail
client to CRLF.

People creating mailserver 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 mesage.

For security reasons, the characters 0A hexadecimal (US-ASCII character
LF), and 0D (US-ASCII character CR) must not be decoded by client
software. To indicate new lines in the body text, a URL should use the
forward slash ("/") character, which client software will translate to
CRLF.

Additional BNF for RFC1738

mailserverurl    = "mailserver:" encoded822addr "/" subject "/" body
subject          = *[uchar]
body             = [body_line] *["/" body_line]
body_line        = *[uchar]

Security

The mailserver scheme is intended 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.

A mailserver 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 mailserver URL
without first showing the user the full message that will be sent
(including all headers, including the subject specified in the URL), fully
decoded, and asking the user for approval to send the message.

Client software must not decode the characters 0A hexadecimal
(US-ASCII character LF), and 0D (US-ASCII character CR). In the subject
field, such decoding would permit header spoofing; there is no need for
these characters in the body field because of the use of the "/"
character.

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

Author contact information:

Paul E. Hoffman
Proper Publishing
127 Segre Place
Santa Cruz, CA  95060 USA
Tel: 408-426-6222
phoffman@proper.com


1
2	IETF URI Working Group
3	Internet-Draft
4	draft-ietf-uri-url-mailserver-01.txt
5	Expires August 8, 1995
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>/<subject>/<body>
51
52	Client software would prepare a mail message with the given <subject>
53	text as the subject header field and the <body> text as the body of the
54	message. <subject> and <body> may have zero length.
55
56	Thus, the "mailto" scheme will be used to give the mailing address of a
57	person or of a mailserver that requires no subject or message body; the
58	"mailserver" scheme is used to give a template that will cause the
59	specified resource to be returned.
60
61	The body text may span more than one line. Any "/" character in the body
62	should be interpreted by the mail client as a CRLF sequence when
63	translating a URL to a mail message.
64
65	Examples
66
67	A URL for a mail response system that requires the name of the file in
68	the subject might be:
69
70	<mailserver:infobot@kwf.com/current-issue/>
71
72	A mail response system that requires a "send" request in the body might
73	have a URL that looks like:
74
75	<mailserver:infobot@kwf.com//send%20current-issue>
76
77	A similar URL could have two lines with different "send" requests:
78
79	<mailserver:infobot@kwf.com//send%20current-issue/send%20index>
80
81	The "mailserver" scheme would also help people get another type of
82	Internet resource, namely mailing lists. For example:
83
84	<mailserver:majordomo@kwf.com//subscribe%20bamboo-l>
85
86	Encoding
87
88	RFC1738 requires that many characters in URLs be encoded. This affects
89	the mailserver scheme for some common characters that might appear in
90	subjects or message contents. Two such characters are space (" ", ASCII
91	hex 20) and forward slash ("/", ASCII hex 2F). Note the examples
92	above that use "%20" for space in the message body. Note further that an
93	unencoded forward slash in the body area is to be translated by the mail
94	client to CRLF.
95
96	People creating mailserver URLs must be careful to encode any reserved
97	characters that are used in the URLs so that properly-written URL
98	interpreters can read them. Also, client software that reads URLs must
99	be careful to decode strings before creating the mail message so that
100	the mail messages appear in a form that the recipient will understand.
101	These strings should be decoded before showing the user the mesage.
102
103	For security reasons, the characters 0A hexadecimal (US-ASCII character
104	LF), and 0D (US-ASCII character CR) must not be decoded by client
105	software. To indicate new lines in the body text, a URL should use the
106	forward slash ("/") character, which client software will translate to
107	CRLF.
108
109	Additional BNF for RFC1738
110
111	mailserverurl = "mailserver:" encoded822addr "/" subject "/" body
112	subject = *[uchar]
113	body = [body_line] *["/" body_line]
114	body_line = *[uchar]
115
116	Security
117
118	The mailserver scheme is intended to send a message from one user to
119	another, and thus can introduce many security concerns. Mail messages
120	can be logged at the originating site, the recipient site, and
121	intermediary sites along the delivery path. If the messages are not
122	encoded, they can also be read at any of those sites.
123
124	A mailserver URL gives a template for a message that can be sent by mail
125	client software. The contents of that template may be opaque or
126	difficult to read by the user at the time of specifying the URL. Thus, a
127	mail client should never send a message based on a mailserver URL
128	without first showing the user the full message that will be sent
129	(including all headers, including the subject specified in the URL), fully
130	decoded, and asking the user for approval to send the message.
131
132	Client software must not decode the characters 0A hexadecimal
133	(US-ASCII character LF), and 0D (US-ASCII character CR). In the subject
134	field, such decoding would permit header spoofing; there is no need for
135	these characters in the body field because of the use of the "/"
136	character.
137
138	Examples of problems with sending unapproved mail include:
139	- mail that breaks laws upon delivery, such as making illegal threats
140	- mail that identifies the sender as someone interested in breaking laws
141	- mail that identifies the sender to an unwanted third party
142	- mail that causes a financial charge to be incurred on the sender
143	- mail that causes an action on the recipient machine that causes damage
144	that might be attributed to the sender
145
146	Author contact information:
147
148	Paul E. Hoffman
149	Proper Publishing
150	127 Segre Place
151	Santa Cruz, CA 95060 USA
152	Tel: 408-426-6222
153	phoffman@proper.com
154
155