Re: mailto security and semantics
Larry Masinter (masinter@parc.xerox.com)
Wed, 8 Jan 1997 19:33:55 PST
To: liberte@ncsa.uiuc.edu
Cc: uri@bunyip.com
In-Reply-To: <199701081639.KAA16742@void.ncsa.uiuc.edu> (message from Daniel
Subject: Re: mailto security and semantics
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <97Jan8.203355pdt."278"@palimpsest.parc.xerox.com>
Date: Wed, 8 Jan 1997 19:33:55 PST
# I'm in favor of this extension, but I recall Roy Fielding's strong
# objection last time it was suggested because of security concerns.
I think the concerns are legitimate, but they're of a similar nature
to gopher://mail:25/HELO%20localhost%15%12RCPT%20TO:%20..... it's
important that implementations get it right.
# I wonder if the sections on unsafe headers and security issues is
# sufficient warning to implementors,
I'll be delighted to add them.
# or if something else is required, such as stronger restrictions on
# the allowed headers.
What would you suggest?
# It might help to include some rationale as to why the unsafe headers
# might be dangerous, or include a reference to a document with such
# discussion.
The exposure for 'mailto' is actually not very high: "unintended
mail". I think the main safeguard is "Don't include any header you
don't recognize without a strong warning, and never send anything
without explicit confirmation".
> While there are
> Internet resources that can only be accessed via electronic mail,
> the mailto URL is not intended as a way of retrieving such objects
> automatically.
# ... though it may be used to do so, at least asynchronously. I think
# this way of talking about a mailbox as a resource is confusing, and it
# gets worse in the following.
I agree it's a little awkward, but I strugged to get the current
wording. The point is that the 'mailto:' URL is not the name of the
data object you get. It's the name of the interaction.
> A "mailto" URL has unusual semantics because the operation of
> "GET"ing such a URL does not usually result in the immediate
> retrieval of an information object. Rather, the GET operation
> merely opens an interactive user session for mailing to the
> designated address with the various header fields set as default;
# This seems to reflect an http bias....
I'm willing to change the URL scheme suggestion to talk about "open"
instead of "GET", but most documents currently talk about "GET".
# Is the "POST" operation in this case activated when the user submits
# the message, as opposed to clicking on the anchor which you called "GET"?
No, the "POST" operation is activated when you click on the submit
button of a form (HTML, PDF, etc.).