[EAI] Quick comments on draft-ietf-eai-mailto-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EAI] Quick comments on draft-ietf-eai-mailto-00
Martin,
Some quick reactions...
(1) This is really ugly. Perhaps nothing can be done about it,
but I think that is worth noting, especially since we have gone
out of our way to make
non-ASCII-string at non-ASCII-string.whatever.tld a value email
address.
(2) It might be a bit less ugly if you used only envelope
addresses (RFC2821-derived) rather than header (RFC2822-derived)
ones. In particular, I really see little need to incorporate
name phrases in these strings and much less need to incorporate
comments. See also (6) below.
(3) It is perhaps worth a comment that "?" is a valid character
in a local-part. More %-encoding, I assume. The first Note 1
in Section 2 doesn't go quite far enough in that regard, even
though the requirement for surrounding "<" and ">" might
eliminate the parsing problem for i18n addresses.
(4) In Section 2's final set of notes (below "Non-ASCII
characters can be encoded in "hvalue"...), your first bullet
says "SHOULD". If the sending system ignores that
recommendation, what do you think will happen? Think someone
might apply the UTF-8 encoding algorithm to ISO 8859-6
characters?
(5) While I sympathize with the reasons for Section 3, it is
handwaving, since the typical context in which a mailto URI
might be used would have absolutely no way to tell at the time
the URI is written.
(6) Your examples should include one in which the phrase and
comments, including characters in the former that require
quoting, are used if you really want to require support for them.
(7) If a relatively simple mailto URI will look like
mailto:%3Ccaf%C3%A9 at %E7%B4%8D%E8%B1%86.example.org%20%3Ccafe@
natto.example.org%3E%3E
then I contend there is a security threat associated with this
system that is not present in the listed RFCs. The problem is
that one of our more important security aids is the user's
ability to inspect a string and determine that it is nonsense or
a threat. I suggest that, for a typical user, the effect of a
string similar to the above is "the eyes glaze over" rather
than, e.g., the implied warning of seeing the domain name (at
least) as an ACE. Put differently, this sort of string makes
it extremely easy for an attacker to hide hostile information in
the string, since no user will be able to render that string
into anything familiar.
best,
john
_______________________________________________
IMA mailing list
IMA at ietf.org
http://www.ietf.org/mailman/listinfo/ima
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.