Re: [EAI] Shepherd report review of mailinglist-02

[John C Klensin <[e-mail]>]

--On Friday, July 13, 2012 09:36 -0400 John R Levine
<[e-mail]> wrote:

>> Also, my proposal of different text for the "%-routing
>> problem", which is  clearer about the source of the problem,
>> in particular that it's an  implementation problem (correct
>> escaping/unescaping) and not an a-priori  problem, hasn't
>> been taken into account, and I don't know why.
> 
> I looked at your language, and it seemed to me less clear than
> what's there.  The problem is very simple, some MTAs mishandle
> addresses that contain % signs.  All we need to do is note it,
> not tell people how we think they should fix it or work around
> it.

Agreed, but I suggest that there are really two separate
problems.  The first is the one you mention.  The second is that
there is a mismatch between the MAILTO syntax and definition
(necessitated by the URI syntax) and the specification of 5321,
essentially 
"no one gets to interpret the local part string at all".  It is
correct to talk about that as an implementation problem, but it
is an implementation problem that is so widespread as to justify
security warnings, etc. Similar problems --and probably similar
appropriate warnings-- apply to the use of a number of special
characters (notably "+" and "/" in local parts versus the use of
those characters in URIs and HTML.  Not the fault of mailto, but
traps for the unwary.  And we have ample empirical evidence that
there are lots of unwary (or indifferent) implementers and
implementations out there.

These are important issues.  Probably RFC 3696 should be updated
some day to be more careful and explicit about it.  Or perhaps
5321 should be updated to complement the warning that while the
spec says that local-parts are case-sensitive one shouldn't
depend on it working with one that notes that, while the special
characters used in URIs are perfectly valid in local parts
according to the spec, one shouldn't plan on having them work
either.

But I see no advantages, and several disadvantages, of opening
up any of that discussion in this document.

Again, just my opinion and YMMD.

   john