[Bug 61698] New: KMail render HTML, block scripts/images

Neil Williams linux at codehelp.co.uk
Sat Jul 26 23:05:37 BST 2003


On Saturday 26 Jul 2003 8:23 pm, sblinux at shaw.ca wrote:
>
> Currently when KMail recieves an HTML message, in an attempt to protect the
> user, it simply displays the html code as the message, and the user has the
> oppertunity to view the message as it was sent if they so wish.
>
> This is quite irritating.

On the contrary, I find it VERY useful and actually quite comforting. ?!

Why not just run a spam filter and set "Prefer HTML to plain text" for folders 
containing emails that don't parse as spam? KMail already allows you to do 
that, but without putting me at risk.

IMHO, this is NOT a bug, it's the single best feature in the entire client.

> It is true a spammer can verify an address is active by embeding unique
> id's in the request for an image, and not rendering the message at all dose

That's the entire (and sole) point of the HTML in spam.

> prevent that, however, when the person does go to view the HTML, their
> address is still verified as the image or script is loaded.

Not on my machines, the email is piped through spamassassin first and 99% of 
all HTML email I receive gets at least 8 points (5 needed for spam status).

Besides, if someone GENUINE sends me HTML email, there is a plain text 
component - that is the critical element. Spam emails so often have no plain 
text or some daft message about getting a 'better' client. A better client is 
one that never activates any HTML in email. (The client in front is a KMail.) 
(Haven't used Mutt but I think it behaves the same way too.)

So, overall, I never activate any HTML email - that's policy!

If I can't read it as plain text, I don't read it at all. After all, KMail 
makes it easy to view the plain text by just clicking on the plain text line 
in the mime list panel. I don't see why you want that changed when KMail 
already has all the options available to you without compromising others.

> I suggest changeing the behavior of KMail so it displays HTML messages
> rendered so they can be read but block scripts/images so that users dont

Please, NO! Genuine HTML email is perfectly readable as plain text BEFORE you 
click to activate. (Not that I ever do.) Your proposal can only benefit the 
spammers. Why? Being selective in what you allow KHTML to receive is NOT a 
viable answer. I involves a lot of pattern matching, very large HTML emails 
will cause failures, lots of smaller HTML emails (as my spamtrap receives) 
will cause intolerable delays in retrieval, maybe even POP server timeouts! 
It's already v.slow on some servers.

Go ahead, try it for yourself. Take a few 10kb HTML spam emails (preferably 
some of those that are sent in base64 just to make it interesting) and write 
a perl script to eliminate 100% of all script, image and a href tags. Oh and 
object, applet, iframe, etc. Now re-write the script to actually preserve the 
content that you find so interesting without restoring any of the matches.

I've tried. I got to 50 lines of Perl and gave up. I now just strip all < or 
< and > or > - that way NO tags will ever activate. Two lines: 
s/<|<|&lt;//ig; s/>|>|&gt;//ig;

Just matching s/<.*>//g; in one line removes all tags alright, along with all 
the content, you may well get a blank page as the match strips out everything 
between the html and /html tags. (Remember that the match is greedy and will 
seek the end of the match as close to the end of the text as possible.)

One of my absolute favourite things about KMail is that HTML email is not 
activated without permission. Please don't change that. Please!!!!!

-- 

Neil Williams
=============
http://www.codehelp.co.uk
http://www.dclug.org.uk

http://slashdot.org/~codehelp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde/attachments/20030726/56e59f77/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  http://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


More information about the kde mailing list