Subject: Re: Last Call: draft-duerst-mailto-bis (The 'mailto' URI Scheme) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Thu, 21 Jan 2010 10:58:50 -0500

--On Monday, November 30, 2009 07:38 -0800 The IESG
<[email-masked]> wrote:

> The IESG has received a request from an individual submitter
> to consider  the following document:
> 
> - 'The 'mailto' URI Scheme '
>    <draft-duerst-mailto-bis-07.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send
>...

Hi.

I thought I had sent notes on this some weeks ago, but can find
no record of having done so, so apologize for the late
submission.

The mailto specification exposes several of the problems with
the interaction between the URI model and the syntactic and
semantic conventions of assorted protocols, especially
protocols that were specified and deployed long before there
was such a thing as a URI.   In this case, that situation is
complicated by the observations that mailto URIs are very
widely deployed, making backward compatibility important, and
that the existing specification in RFC 2368.

Because of the lateness of this review, I'm ignoring issues
that I don't consider especially significant.   I believe that
the following issues _are_ significant:

(1) Special characters, particularly "+", and percent-encoding

The specification talks about the need to encode various
special characters, particularly characters that have reserved
meanings in the URI specification such as "%" and "/".  One of
the failings in prior mailto specifications was that the state
of "+" was left ambiguous wrt whether it needed to be encoded
or not.  "+" is heavily used in subaddress techniques and,
partially because of the interactions noted in Section 5 of
this document, has caused a problematic interaction with the
use of the same character as an encoding for a blank space in
web forms.  The problem is noted and discussed in more detail
in RFC 3696.

Despite the discussion in the third paragraph of Section 5,
the document leaves ambiguous whether the correct 
representation of an email address like [email-masked]
in a mailto URI is 

   mailto:[email-masked]      or
   mailto:[email-masked]

and whether either of those, if interpreted in a web form
context, is expected to be treated as

  [email-masked]              or
  "john ietf"@example.com

both of which are valid addresses under RFC 5321 (see the
production for "qtextSMTP" there -- the 
"john\ ietf"@example.com form is not required.

It is also worth noting that, while 

   mailto:[email-masked]           and
   mailto:[email-masked]

are considered equivalent in this specification, the email
addresses 

   [email-masked]               and
   [email-masked]

are formally different and may have quite different semantics
(only the final delivery SMTP server knows).

That ambiguity is not just an encoding issue and difficulty for
those who use subaddresses.  It creates a vector for potential
attacks that is not noted in Security Considerations (that
section concentrates more on social problems, such as address
harvesting and information exposure, than on actual attacks on
the mail protocols and system).  More generally, while the
document makes the observation 

	"Care has to be taken both when encoding as well as when
	decoding to make sure these operations are applied only
	once."

(from the end of Section 2(1)) it does not discuss how that is
to be done, nor does it note the risks of not doing it in
Security Considerations.  That is important because there is
some anecdotal evidence that the rule is widely violated,
especially in web applications that move information back and
forth between mailto URI and email address formats.

(2) I18n issues

While the authors have done a careful and thoughtful job of
trying to anticipate the needs of the long-term (i.e.,
post-experimental) EAI work, there are possible ambiguities
that are not considered in addition to the "alternate address"
issue mentioned in Paragraph 3 of Section 1.  Some of the
important ones of these are the non-ASCII equivalent of the
discussion above: Because RFC 5321 fundamentals that are not
changed (or proposed to be changed) by the EAI work imply that

   [email-masked]
   [email-masked]                and
   [email-masked]

represent three different target mailboxes (unless the final
delivery server makes some decision to the contrary).  Again,
extreme care about the sequencing of decoding and other
interpretation can bypass the problem, but the document is not
nearly cautious enough about this and especially the security
and "user surprise" implications of trying to do that in
distributed modules so that operations are performed out of
order and/or other than exactly once.

(3) Interactions between RFC 5321 and 5322.

The specification covers over the subtle differences between
envelope and header addresses, treating addr-spec and
?to=<hfvalue> as effectively equivalent.  Differences between
the implications and semantics of the envelope/delivery address
and the header field "To:", which are quite clearly
distinguished in RFC 5321 and 5322 are ignored or prohibited.
Possibly that is a reasonable design choice, but it is not
discussed.  In my opinion, if the functionality the difference
implies is going to be inaccessible via the mailto URI, that
decision should be discussed, if only to prevent confusion,
poor implementations, and misuse.

thanks,
    john klensin