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

IETF URI Working Group
Internet-Draft
draft-ietf-uri-url-mailserver-00.txt
Expires July 23, 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>/*[<header>/]/<body>

Client software would prepare a mail message with the given headers and
the <body> text as the body of the message.

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.

Headers are given in RFC822 format, and it is likely (and probably
preferable) that only a "Subject:" header be included. Headers are given
without spaces after them, such as "Subject:current-issue".

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/Subject: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 (after the "//") 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.

Specifying Headers

A mailserver URL can include headers for the client software to add to
the message. Each header is in the form:

<header-name>:<text>/

Thus, a URL with a "Subject:" header, a "X-magic" header, and a body
might look like:

<mailserver:files@kwf.com/Subject:archive/X-magic:18rtg//mail%20arch17>

See the "Security" section below for important considerations for using
headers.

Additional BNF for RFC1738

mailserverurl    = "mailserver:" encoded822addr "/" *[header "/"]
                   "/" body
body             = [body_line] *["/" body_line]
body_line        = *[uchar]
header           = encoded822header ":" header_text
encoded822header = 1*xchar  ; further defined in RFC822
header_text      = *[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 those specified in the URL), fully
decoded, and asking the user for approval to send the message. 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 goes to an unwanted party, such as through a "cc:" or "bcc:"
header
- 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

If a mailserver URL specifies headers, these headers can cause security
problems, such as identifying the sender to a malicious third party.
Further, headers other than "Subject:" can cause undefined actions in
some mail programs that may compromise security. Security-conscious mail
clients should scrutinize the headers and their contents before
including them in mail messages; some clients might even choose to
ignore some or all of the headers other than "Subject:" in a URL.

Author contact information:

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


1	wakaba	1.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