Subject: Re: HTML in e-mail

From: Vernon Schryver <[email-masked]>
Date: Fri, 12 May 2000 21:37:39 -0600 (MDT)

} From: Christian Huitema <[email-masked]>

}                        ...  Maps and pictures, songs and recordings come to
} mind. There was a rationale for creating MIME.

Certainly!  there are cases where pictures are best or even necessary.

} Framing the debate as ASCII versus HTML is a bit reductive.

true, but if you could get the HTML above all else enthusiasts to consider
the possibility that the typical ASCII wrapped in HTML email is stupid,
progress might be made.  When was the last time you saw an HTML email
message of any flavor that was not merely pure ASCII (or one of the fancy
character sets that don't need HTML) slightly prettified?

}                                                             The real
} separation here is self-contained versus network based. Carrying a picture
} in a message is definitely valuable, carrying a link to a picture that is
} stored on some random web site creates an obvious privacy risk -- the URL
} itself can be the hidden communication channel that tracks you.

That's an important point about URL'st that I've been trying to make,
apparently with absolutely no success.  However, I'm not sure yours is
the important separation.  Even self-contained pictures can carry security
risks.  What if in the name of compression, pictures are programs that
render themselves?  What about a program that makes navigating among a
bunch of pictures easier, perhaps in the popular style of active buttons
on web pages?  I think the separation is more "active" vs. "static," with
"active" understood by the professionally paranoid who worry about covert
channels and so forth.  Or at least with a sandbox kind of attitude, and
to blazes with the claims that the user unfriendliness of a sandbox trumps
security worries.

  .............
 
] From: "James P. Salsman" <[email-masked]>

] ...
] > How can [email-masked] know if the attached executible 
] > file is safe or not?
] 
] If I knew that, I wouldn't be trying to stop complacency 
] about the promiscous exchange of self-extracting archives.
] 
] The best attempts to address the issues so far involve 
] "certificate-signed executables", a cryptological method of 
] verifying that some certificate authority approves of a 
] given fixed string of bits.  Do a search on that and/or 
] "application signing" to learn more.  A caveat in practice, 
] though, so far signed executables do not seem to have 
] caught on.  At best, they are complicated to get right and 
] involve an increased support cost if done wrong.  At worst,
] the certificate authorities, who often have a strangle-hold 
] on such technologies, often because of poor regulations, 
] are too greedy to have helped these catch on yet.

I hope that's not the very strange notion popular in some areas that
authentication and authorization are the same.  That an ActiveX applet is
signed with a large company's key or even my key should *NOT* imply that
is authorized to do anything and everything to your computer.

Never mind that in the case at issue, we should expect that a good version
of the visual basic worm would sign its transmissions with the console
user's key, since one wouldn't want to force the console user do something
so user-unfriendly as type a passphrase merely to sign email.

 ..............

> From: Jacob Palme <[email-masked]>

> ...
> Why should not graphics be of value in e-mail, when it is of
> value in most other media like web pages, books, newspapers,
> magazines, etc? Why should the e-mail medium not benefit
> from graphics to enhance understandability and readability?

>                                    ...  This means that
> neatly formatted messages give a cost/benefit gain, if
> the number of recipients of a message is over a certain
> limit. Thus, neatly formatted messages are more worth the
> cost if you are mailing to a large mailing list than to
> a single recipient.

>                                ... I often include screen
> shots showing how ther software does not work properly.

> ...
> This is, I believe, the crucial point. HTML in e-mail
> has got a bad reputation, not because the idea of
> graphics in e-mail is wrong, but because it is
> used, tooo much, by people sending us things
> we would prefer not to get.

My translation of that is:

  - in a very few cases, such as screen shots of bugs, HTML pictures 
   are worth a 1000 words and the extra trouble required of the recipient
   to deal with their security problems.  Never mind whether a screen
   shot would be better sent as GIF, TIFF, JPG or other forms instead of
   HTML, or whether in practice the HTML would consist of more than an
   <HREF> to a .jpg or .gif elsewhere.

  - experienced people who are not employed by the mass media don't like
   HTML in email in part because it is commonly used if email were a
   cheaper, more direct, and less voluntary kind of broadcast TV.

Many people agree with both sentiments.

They don't address insanity such as Content-Type: application/ms-tnef.
As far as I can tell, that's Microsoft's embrace-and-extend alternative
to the open standard foolishness of sending plaintext ASCII with HTML.
Judging from some of my private correspondents, in practice it cannot be
turned off by experienced, entirely computer literate but not professional
expert users.  As others have pointed out, one of the unintended evils of
such things is that users are trained to open without thinking any and
all attachments.

In other words, those who advocate insecure systems such as Windows 98 or
Windows NT 4.0 as installed by anyone except an expert are not only
culpable for the insecurity of those systems, but also for forcing
100,000,000's of people to develop the inexcusably insecure habit of
unthinkingly opening any and all email attachments.

Vernon Schryver    [email-masked]