Re: Stripping multipart/alternative messages and accepting the text/plainpart.

[Jonathan Larmour <jifl at jifvik dot org>]

On 28/02/12 00:46, Per Bothner wrote:
> Yeah - the linked-to page [0] gives good reasons for not allowing
> arbitrary HTML in email.  However. HTML has many benefits [1],
> and if you restricting yourself to a safe-and-sane" subset of HTML [2]
> then I don't think the reasons in [0] are valid [3].
> 
> This is similar to blog sites that allow comments in a restricted
> subset of HTML.  With just a Small Matter of Programming [4], we
> should allow the same.
> 
> [0] http://www.frontierfleet.net/email/
> 
> [1] Re-flow, section headers, unambiguous hyper-links, lists/tables.
> optionally images, em/strong/code, math, etc etc.
> 
> [3] Is there some existing suitable standard for "safe-and-sane" HTML
> for emails (or blog comments)?  I'm guessing there is.

I've never heard of any such standard, but more importantly I don't think
you'll find any HTML-generating mail clients which restrict themselves to
using this subset, so even if such a standard exists, it won't help.

If we just imposed our own rules on which HTML tags are allowable, this
would be a maintenance headache... not just trying to keep up with what
clients can generate, but also the endless users who would get confused
and complain why one message with certain characteristics works, and
another fails. Bear in mind that most of those using HTML clients have no
way to control the actual HTML produced.

> [4] (a) The concern about bad font sizes doesn't apply to restricted
> HTML - and regardless, the mail reader or user could override that.
> (b) The concern about a text mode HTML reader displaying raw tags
> seems pretty silly.  Haven't they heard of lynx/elinks/...?
> Processing restricted HTML isn't that difficult.
> "Many people still use terminals instead of computers to read email."
> Name two.

Perhaps more importantly, we have publicly viewable mailing list archives
for all lists. It would be very challenging to allow those to continue to
be valuable resources while also keeping them both legible and, most
importantly of all, safe. There are already enough spammers and virus
writers exploiting loopholes, and we would get into a lot of trouble if we
end up facilitating that at any point.

> (c) Digest creation is a bogus concern.  The digester can run
> the HTML though lynx before creating the digest - if anyone cares.
> (Are digests good for much besides having people incorrectly reply
> to the digest?  People who are competent to use digests correctly
> are competent to set up filters.)

I know from my project that there are quite a lot of people who only sign
up to digest versions (never understood it myself, but they're there).

If the whole point is to allow the use of HTML features as you mentioned
in your point [1], then isn't the corollary that stripping these "rich
text" features out is likely to cause problems if people are expecting
them to be respected? Markup needed for context will be missing, images
will be stripped, layout will be mangled, and so on.

> [4] I realize nobody has spare time, so I'm not complaining.  But this
> luddite "HTML email is evil" mantra gets tiresome.  It needs to stop.

I'm sure there could be technical solutions to all the above, but it would
require a lot of work.

I think for what you want, what you should be asking for is for each
project to move to web forums instead of email. I think that would be a
hard sell.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine