To: firstname.lastname@example.org Cc: email@example.com In-Reply-To: <199701081639.KAA16742@void.ncsa.uiuc.edu> (message from Daniel Subject: Re: mailto security and semantics From: Larry Masinter <firstname.lastname@example.org> 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.).