On Tue, December 7, 2004 1:18 pm, Timothy Payne said: > First of all you left off what was above and below what you posted. > The page was not made for this list, it was an explanation of why we > do not read unknown HTML mail at my company. Huh? I posted all the reasons given. You posted it to someone on this list so I took a look. Here's what I skipped from above: Thanks to Tom Mitchell A few reasons NOT to read HTML email: HTML provides a number of risks and non features that we wish to avoid. Don't really see why you're upset that I omitted it. >> HTML permits scripts (Java and Java scripts) >> HTML permits tag images >> HTML can set cookies that other sites might inspect >> HTML facilitates 'active content', goodness what does active imply. >> - HTML doesn't require the use of these things and all of them >> can be configured away by the recipient. > > Permits is not the same as require, and judging by this list many people > can't even configure their mailer to send text only. So for the average > computer user this applies. But it's not the average computer users that are complaining, and there's been no reported abuses on this list do to these features that i'm aware of. >> HTML is not a universal WYSIWYG (what you see is what you get) >> HTML and the 'equivalent' text of a MIME message may not be equal >> HTML can Carry mixed character sets unnoticed by the sender >> - Why are any of these a concern? > Because what you read or send may not show up as it was intended. As I mentioned elsewhere, text only messages may be displayed in a different font or word wrapped in a different way. The meaning is not lost. If this criticism was all that important the Web wouldn't be as successful as it is (ie. if HTML is good enough for web pages, its good enough for email) I get email from people all the time in HTML and have *never* had this issue. I think you might be over estimating this as a problem. >> HTML permits volatile external content references >> - In fact many plain text messages provide links to external content, >> in fact *your* plain text message included a URL to external content! >> This "reason" doesn't pass the smell test. > You don't think someone can add code to an HTML message to fetch outside > data? My link had to be clicked on, it was not coded into the message to > display when opened. In fact in my email client no outside links are followed unless explicitly clicked on. This is a recipient problem, not a sender problem. Again, you're punishing good users of HTML for the sins of the spammers. > HTML can carry text that is problematic to index / search >> - Huh? The entire web is based on HTML and google indexes it just fine > Yes, Google indexes text, and the pages with the best text are ranked > higher, second is links. And I'm sure they have spent millions doing > that, because that is their business. The point was that HTML does not inhibit indexing or scanning by anyone. Software has evolved. >> HTML facilitates spammers >> HTML facilitates spyware >> HTML rich content hobbles off line interaction. >> - How? I receive HTML email from family members, no problem. > Like I said you left off important items from the page. > I said if you don't know the sender delete the message. Well I left off *your* remedy because its not one I use personally and it wasn't a reason but a solution. I receive HTML all the time and have absolutely none of these problems that you think exist because of HTML. >> HTML facilitates virus payloads (at work some of must use WindowZ) >> - Sucks, but is not the senders problem, its yours and your companies. >> In fact, viruses infected files can be attached to plain text >> messages just as easily, a properly configured client won't be >> at risk in either case. > It's not what's attached to the email, it's what is coded inside. So make sure your client does the right thing. Mine does. Go ahead and send me something you think will wreck my system, I promise to open it up and take a look :o) >> >> HTML permits you to get fired by triggering pornographic references >> "censorware" to catch employees trying to access "bad" sites >> that corporate filters trigger, i.e. trigger HTTP proxy >> (porn, hate sites, hacking sites, etc) >> - This is just laughable > You don't think an HTML email can make a call to another site for data? Only if the client lets it. You're attacking the problem at the wrong end. >> HTML messages are 2 to 50+ times larger than the equivalent text >> - This seems like the only issue that has any real weight behind it >> and since the list is voluntary.... If this is such a big problem >> why doesn't RedHat filter HTML email rather than putting up with all >> the bandwidth consumed talking about it? In fact, why respond >> on-list asking people to stop posting in HTML if this is the issue? > It is customary to post to this list in plain text. Just like the fact > that remove my shoes when I enter the Buddhist Monastery I attend. If I > did wear my shoes I would be reminded about it, but if I refused I would > not be kicked out or yelled at. Well we're discussing if this custom is still in place for appropriate reasons. >> I don't particularily like HTML messages, but the reasons you cite don't >> really stand up to inspection. In fact, a counter argument could be >> made >> that HTML messages could include content using colour and images to >> explain solutions much better!. >> > Before posting what you disagree with, BTW you did not include the authors > name, I spoke with several people first. One of which has a PhD and runs > a computer research lab at a major University, and every one agreed with > what was written. Fine. They may well be true in certain circumstances. But I still think your solution to the problem is wrong. It should not be to outlaw all HTML email it should be to solve the core issues with the clients that permit abuse. > > These are my opinions, not of the author. > No problem. I still don't think the solution is to ban HTML. Cheers, Sean
