Re: Second round for new URL scheme (mailserver)

> 
> Thank you for all the comments on pre-draft 1. Below is pre-draft 2, which
> I think answers all the issues brought up. In doing so, it also opens a few
> more that should be discussed before I commit it to full IETF draft-hood.
> 
> Security: I added a discussion about the need for client software to show
> the user the full message before sending it.
> 
> Name: Based on Dirk's OK, I changed the name of the scheme to "mailserver",

I wish nice short 'ms' was more in favor...

> which is already quasi-reserved in RFC1738. After reading the pros and
> cons, I still chose not to try to extend mailto because I'm pretty sure
> many current versions of Web clients will break if I did. This is not to
> say that we can't make changes to any existing schemes. However, the
> changes made here are new fields and the URLs need to be parsed completely
> differently. To me, the makes "mailto" useful for people and "mailserver"
> useful for, well, mail servers.
> 
> Scalability: Dirk pointed out that whatever we do now should be made
> scalable so that it doesn't have to be revised later (and to prevent the
> need for a third "mailxxx" scheme!). Thus, I added the optional additional
> headers at the end of the URL, and pointed out the security problems of
> them.
> 
> Encoding: I added notes about encoding.
> 
> If there aren't any big problems shown this week, I'll turn this into a
> real IETF draft and let the folks at the IANA know that "mailserver" has a
> draft definition. I'll also contact the big Web client writers so that it
> can be included.
> 
> --Paul Hoffman
> 
> ===============
> 
> Status of this memo
> 
> <insert generic Internet Draft preamble here>
> 
> 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>/[<other-headers>]
As noted, this is better:
      mailserver:<rfc822-addr-spec>/headers:dat//<body>/<lines>

Issues:

'variables': full name (needed for some listservs), mailfrom, form
	     entries
Form data formatted into message
Encoding types
Possible support for email forms: structured ascii, EDI/MIME, etc.

Although some of these can't be implemented easily, the syntax should
expect them.  Variable expansion might be hard, but needed.
How about ${name} style.  


> Client software would prepare a mail message with the <subject> text as the
> subject 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.
> 
> 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/>
> 
> 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 two examples above that use
> "%20" for space in the message body.
> 
> 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.
> 
> Additional headers
> 
> A mailserver URL can include additional headers for the client software to
> add to the message. Each header is in the form:
> 
> <header-name>:<text>/
> 
> Thus, a URL with a "bcc:" header might look like:
> 
> <mailserver:infobot@kwf.com/current-issue//bcc:jean@kwf.com/>
> 
> See the "Security" section below for important considerations for using
> additional headers.
> 
> Additional BNF for RFC1738
> 
> mailserverurl    = "mailserver:" encoded822addr "/" subject_text "/"
>                    body_text "/" *[extra_header "/"]
> subject_text     = *[uchar]
> body_text        = *[uchar]
> extra_header     = encoded822header ":" extra_text
> encoded822header = 1*xchar  ; further defined in RFC822
> extra_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) 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 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 has additional headers, these headers can cause
> security problems, such as identifying the sender to a malicious third
> party. Further, the additional headers can cause undefined actions in some
> mail programs that may compromise security. Security-conscious mail clients
> should scrutinize the additional headers and their contents before
> including them in mail messages; some clients might even choose to ignore
> some or all of the additional headers 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
> 
> 
> 


-- 
Stephen D. Williams    25Feb1965 VW,OH      sdw@lig.net http://www.lig.net/sdw
Senior Consultant      510.503.9227 CA Page 513.496.5223 OH Page BA Aug94-Dec95
OO R&D AI:NN/ES crypto     By Buggy: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Firewalls/WWW servers ICBM: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W work
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.29Nov94

Received on Wednesday, 11 January 1995 01:58:33 UTC