# Mailserver URL proposal

Dirk Herr-Hoyman (hoymand@gate.net)
Tue, 19 Jul 1994 21:33:41 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Martin Hamilton: "Re: Mailserver URL proposal"
- Previous message: Michael Mealling: "Re: New URC Specification is ready...."
- Next in thread: Martin Hamilton: "Re: Mailserver URL proposal"
- Reply: Martin Hamilton: "Re: Mailserver URL proposal"
- Maybe reply: Dirk Herr-Hoyman: "Re: Mailserver URL proposal"
- Maybe reply: Paul Rarey: "Re: Mailserver URL proposal"

    Date: Tue, 19 Jul 1994 21:33:41 -0400

    Message-Id: <199407200133.VAA98546@inca.gate.net>

    To: uri@bunyip.com

    From: hoymand@gate.net (Dirk Herr-Hoyman)

    Subject: Mailserver URL proposal

As I began the call for a mailserver URL, I am now trying to back this up
with a concrete proposal. I know that there are some parts that may be
controversial, but I still feel this URL is needed in some form. The
mailto URL is insufficient.

Larry had asked me to look at the MIME mailserver content type.
Unfortunately, this is inadequate as a URL, as it only specificies some
headers (the Subject) and leaves the body as itself.

So, I came up with the proposal you see below, which I tried to make as
simple as possible, yet cover all the mailservers we are likely to see.
The part I am not sure about is substituting at run time, which feels alot
like a form. Here goes (and I've got my bullet-proof vest on, so fire away
:-)

--- cut here ---

Mailserver URL

There are numerous mail servers that enable the retrieval of some
reasource by commands embedded in a mail message. Since there
is no uniform method for how the commands are embedded (Subject
header, body of the message) nor for the syntax of the commands
a general purpose mailserver URL is defined.

This URL works differently than others defined to date, as it
delivers the resource asynchronously to a mailbox, rather than
synchronously on a TCP port, ready to be used directly. However,
as there is significant use of mailservers such a URL is needed
to accommodate current practice. Such servers serve an audience
that is not directly connected to the Internet and are likely
to remain important into the foreseeable future.

URL:mailserver://<rfc822-addr-spec>/<headers>/<body>

headers = *[ *xchar "/" ]
body = * bodysegment "/"
bodysegment = *uchars | *substsegment
substsegment = "?" *uchars | *uchars

In essense, the mailserver URL is composed of lines of text, with
end of line represented with a /. The mail header is separated from
the message body with a //, representing a blank line. This is, then,
a literatal translation of an RFC822 message into a URL form.

In order to be delivered to the correct mailbox, From: header,
with a valid e-mail address, should be included in the mailserver
URL. As this is a run-time binding, it will be up to the client
software or other agent utilizing a mailserver URL to supply such
a line.

Other run-time bindings might be desirable, such as adding the
full name to a "subscribe" command in the body of the message.
For these a "?token" is used to signify additional information
is needed. This could be filled on thru a forms mechanism on
a client, for example.

Examples:

The static URL, found in an HTML document for example, is:
mailserver://almanac@joe.ext.vt.edu//send%20joe%20june%201994%20feature%201

Actual URL used is:
mailserver://almanac@joe.ext.vt.edu/From:%20hoymand@gate.net//send%20joe%20j
une%201994%20feature%201

This sends the message "send joe june 1994 feature 1" to the email
server at almanac@joe.ext.vt.edu. The response will be delivered to
hoymand@gate.net.

mailserver://listserv@uhupvm1.uh.edu//subscribe%20pacs-l?fullname

This URL is used to send a "subscribe" message. Note the use of
"?fullname", which is means that additional text, in this case
a full name, is needed.

The exact semantics of how the "?token" are used are left undefined.
The "token" string could be used in a prompt for input by a
client application. However, there is no guarantee that the string
"token" has any meaning, other than as a place holder.

Security Considerations

This URL is essentially a means to send SMTP mail. Since the From
address is to be filled in at run-time, it could be a vehicle for sending
forged mail. However, such forgery is already possible thru executing
mail transport agents directly, such as sendmail, or in POP mail clients.
This URL does not create any higher degree of insecurity in SMTP mail,
though it could contribute to an already insecure situation

    --
    Dirk Herr-Hoyman <hoymand@gate.net> |                      Practice
    CyberBeach Publishing               |       random acts of kindness
       * Internet publishing services   |          and senseless beauty
    Lake Worth, Florida, USA            |
    Home Page: <URL:http://www.gate.net/~hoymand/cyberbeach.html>
    Phone:     +1.407.540.8309

- Next message: Martin Hamilton: "Re: Mailserver URL proposal"
- Previous message: Michael Mealling: "Re: New URC Specification is ready...."
- Next in thread: Martin Hamilton: "Re: Mailserver URL proposal"
- Reply: Martin Hamilton: "Re: Mailserver URL proposal"
- Maybe reply: Dirk Herr-Hoyman: "Re: Mailserver URL proposal"
- Maybe reply: Paul Rarey: "Re: Mailserver URL proposal"