Re: mailto security and semantics

"Roy T. Fielding" <fielding@liege.ics.uci.edu> Tue, 14 January 1997 01:58 UTC

Received: from cnri by ietf.org id aa06516; 13 Jan 97 20:58 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa27409; 13 Jan 97 20:58 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA14428 for uri-out; Mon, 13 Jan 1997 20:22:53 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA14423 for <uri@services.bunyip.com>; Mon, 13 Jan 1997 20:22:16 -0500
Received: from paris.ics.uci.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05983 (mail destined for uri@services.bunyip.com); Mon, 13 Jan 97 20:22:09 -0500
Received: from liege.ics.uci.edu by paris.ics.uci.edu id aa10516; 13 Jan 97 17:02 PST
To: Larry Masinter <masinter@parc.xerox.com>
Cc: uri@bunyip.com
Subject: Re: mailto security and semantics
In-Reply-To: Your message of "Wed, 08 Jan 1997 19:33:55 PST." <97Jan8.203355pdt."278"@palimpsest.parc.xerox.com>
Date: Mon, 13 Jan 1997 17:02:47 -0800
From: "Roy T. Fielding" <fielding@liege.ics.uci.edu>
Message-Id: <9701131702.aa10516@paris.ics.uci.edu>
Sender: owner-uri@bunyip.com
Precedence: bulk

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

It's a little more than that -- the really unsafe headers are those
that cause local file import or write actions to take place before
the message is sent.  Likewise, if the body is allowed to be given
within the URL, then you also need to be concerned about file and
shell command escape-codes in the body text.  Unfortunately, these
things are completely application dependent, so I'd agree that the
best we can do is simply list the possible problems in the security
section, along with the safeguard mentioned above.

.....Roy