--On Tuesday, June 17, 2014 09:31 -0400 Ted Lemon
<ted.lemon@xxxxxxxxxxx> wrote:
> On Jun 17, 2014, at 9:26 AM, John C Klensin
> <john-ietf@xxxxxxx> wrote:
>> When criteria of those types are used, plain-text
>> email preferences will always lose, no matter how many of us
>> (or even non-engineers) prefer them for performance, security,
>> efficiency, or other reasons.
>
> FWIW, non-flowing, non-indentable plain text is a royal PITA
> for me when I'm doing document reviews, so I have a lot of
> sympathy for those product managers. The idea that
> indentation and flowable text can have security impacts is
> kind of sad.
Red herring, I think. As Tony pointed out, RFC 2646 is out
there, does work, and few if any of us who prefer plain text
mail to HTML have any problems with it. When it is necessary,
I'm also willing to give up some convenience for enhanced
security and privacy.
The things that I think have security (or significant
operational) impacts include tracking beacons embedded in
messages to tell the sender (at least) when or if they were read
(privacy problem), embedded large images or text that is
automagically downloaded when the message is opened or earlier
(potential DoS attack), embedded malware and scripts of multiple
flavors even if not intentionally hostile, and so on.
It is probably too bad that Rich Text didn't get and keep
traction for those who want the ability to, e.g., color for
format text without exposing themselves to the risks above (and
others). It is equally unfortunate that there are not more MUAs
around that can provide a reasonable interpretation of HTML
without following external links (either pull or push) or doing
anything else questionable without significant control by the
user. But those things didn't happen. I'd like to believe that
is because there isn't sufficient marketplace demand, but the
"sexy demo" and "designed for people who don't want to have to
either learn or think about their tools" issues at best distort
whatever demand might otherwise exist.
john