At 10:16 AM 2002-07-07 -0700, Chuq Von Rospach wrote:
On 7/7/02 10:02 AM, "Bernie Cosell" <bernie @
>> On 7 Jul 2002, at 9:39, J C Lawrence wrote:
>> ... Properly tagging
>> and stripping references to non-message hosted content in HTML email
>> without also crippling/stripping the actually useful aspects of HTML
>> email however is a bitch. Perhaps I've been overlooking the obvious but
>> I've yet to come up with a scheme for that I can't also trivially poke
>> holes in.
> What about reading your HTML-email using a rendering client that cannot
> access the Internet [and, while you're at it, doesn't include a
That works. JC is thinking instead of neutering it in the list server.
I think at some point, however, you have to stop babysitting the user.
Protecting them from dangerous code coming through the server is one thing.
Privacy issues ought to be left to the user to resolve, not the server.
Absolutely. In fact, this whole issue of filtering viruses is a complete
waste of time. Just forward the viruses to the users and let their virus
programs deal with them. And cross site scripting? That is a privacy
issue. Just tell users that it is up to them to figure out which scripts
are safe to run and which are not --- just because you sent them the
scripts from your web site while they were looking at your list archives,
well, that is their problem, not yours.
HTML is a programming language. It had pretensions of being a markup
language at one point, but that is long gone.
When you allow people to mail you programs, and then you run them through a
Microsoft interpreter, eventually people will discover more holes.
Eudora also has a bowdlerized HTML sort-of formatter that does not access
img tags, deal with scripts, active X or Java. If it did not, I would not
trust Microsoft's formatter, I would figure out something else to do.
By the way, I alluded to something above, and if you did not understand it,
I will make it clearer:
You will have to figure out the issues involved in neutering HTML in order
to allow your users to view your archives from the web. If you actually
attempt to display a mimed message by allowing the user to select the part
of the message and then feeding the content to the user with the original
type and encoding, then you will, for example, present a text/html message
in text/html. And if you do it in the context of your web site, you are
introducing a "Cross site scripting vulnerability". In order to do this
safely, you have to somehow expurgate the html, removing scripting, and,
while you are at it, web bugs to avoid the problems with referrer URLs that
may be used to monitor an end user's activities on your web site, and/or
expose URLs that might contain authorization tokens (if, for example, you
with a parameter that carries authorization).
Since you will have to expurgate the HTML to make it cross site scripting
and referrer URL safe, and since this is widely held to be a responsibility
of the site that displays the html that they are passed, then you might as
well do it upon distribution rather than later when you archive the html.
Since the goal will be to display the stuff in the right character set, and
the right type and the right encoding, eventually, everyone will be forced
to do something like Mj2 does for their archive viewing --- they use the
original mime types, encoding, character sets and so forth to hand the
segments to the browser. If someone sends a x-application/virus to the
list, in base64, they will dutifully record this in the archives and then,
when the virus is viewed, present it (and the browser will likely ask,
"Infect or save?")...this is what you are probably going to have to do to
make archive segments viewable.
a message segment runs in your site's context, has access to the cookies,
to the form variables, and to other such things as that will allow the wily
hacker, if they desire to, to log in to the web site that holds the
archives as the user. If you decide to display some html, it is your job
to clean it up.
And if you plan on archiving these messages and then actually allowing them
to be re-played, you have to (a) clean them up or (b) Tell your users that
all of the security problems that anyone cares about in your products are
"Forgive him, for he believes that the customs of his tribe are the laws of
-- George Bernard Shaw (1856-1950)
Nick Simicich - njs @