[plug] HTML mail (partial flame and suggestions)

[Alex Nordstrom]

On Thursday, 30 Sep 2004 19:20, Tim White wrote:
> Firstly, if a person sends an email in MIME format with a test part
> and HTML part, why shouldn't this be allowed? As far as I know most
> text based email clients are MIME compliant and the message is
> normally sent text part first so it's not like they need to scroll
> down past lots of html to see it. (As I don't use a text based client
> I could be wrong so please correct me.) If it really bugs some people
> then they can set up a filter to pipe all emails through a html2txt
> program and not have to worry again. (Not trying to flame people, I
> my self have been restricted to shell access of emails before[1])

I guess that might have been my post sparking this. Good thing I'm 
wearing my asbestos. ;)

Apart from what's already been pointed out in terms of processing and 
bandwidth requirements, security issues, and the issues of presentation 
on clients favouring HTML when it is present (I use KMail, where this 
is not an issue), which I see as the most important ones, also consider 
the following:

 - It's a common property of spam, and will incur a hit from most spam 
filters, such as Spam Assassin in its default configuration.

 - While most clients may be MIME compliant, few HTML e-mails are W3C 
compliant. In the interest of communicating effectively, taking chances 
like that seems unnecessary.

 - Most people who do sent HTML e-mails are not even aware that they are 
doing so; hence, any advantages it may be perceived to have are not 
used.

 - HTML is a language to encode primarily structural information about 
hyperlinked documents inline, yet in e-mails, it is often used for 
formatting, which is not only incorrect application, but poses a 
usability threat to the recipient. Furthermore, there is rarely a need 
to encode structural information in something as brief as e-mail 
communication.

 - There are rarely any benefits to presenting e-mail as HTML. Any 
inclusion in a system of a subsystem that serve no purpose is a great 
way to offend engineers.

 - Expecting others to donate their time, bandwidth and processing power 
to deal with such non-compliant, unintentional, and nonfunctional 
content is simply "not cool".

Note: I neither flame nor ignore (except in the -- so far hypothetical 
-- case where HTML makes the difference in flagging a legitimate but 
suspicious message as spam) individuals who do use HTML e-mail, as it 
is most often simply a case of bad default configurations and lack of 
awareness, and my e-mail client deals quite well with it without extra 
effort on my behalf. I do, however, advise against the use of HTML for 
the the sender's own benefit, as it increases their likelihood of being 
noticed. No one filters out e-mail for being plain text.

-- 
Alex Nordstrom
http://lx.n3.net/
Please do not CC me in followups; I am subscribed to plug.