Re: mailto security and semantics

[Larry Masinter <[e-mail]>]

# 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.).