[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdepim-users
Subject:    Re: [kdepim-users] KMail - Replying in HTML
From:       John Murphy <murphyjj () bigpond ! net ! au>
Date:       2010-08-04 4:02:33
Message-ID: 201008041402.33449.murphyjj () bigpond ! net ! au
[Download RAW message or body]

On Wed, 4 Aug 2010 01:17:34 pm Thomas Taylor wrote:
> HTML is a known cyber attack vector,
So you browse with Lynx then?
And as someone who works in risk - everything is relative.
Websites are possibly more dangerous than mail (phising aside).
Risks (like HTML mail) need to be managed - and if you think that by "translating" the message keeps you \
safe - well that's your call. Let's face it HTML mail is widespread and a defacto standard in many \
sectors - whether you like it or not. Given that's the case, denying the option in KMail (or at least the \
ability to reply in HTML) is just denying users interactions with those sectors. I have been around a \
long time - and can remember when the REAL IT guys (mainframe people) could not see the value in document \
structures at all. They could not see the value in moving aways from fixed length records - and thought \
everyone should stick with that. Their argument was almost the same as Frank Thieme's (above):
"As eMail is about text, so why do you need HTML for it?" 
"As data processing is about data, what do you need text for?"
Anyway, I suspect we shall see the HTML reply facility added later if not sooner - I just hope it is done \
in a positive way with appropriate management tools for risk, not from the negative sentiments the \
purists (not a derogatory term) like yourself so often display. BTW, I almost exclusively use non-HTML \
for everything, including answering HTML mail; but I do not wish to force my ideas on anyone else by \
denying them functionality. Regards,
johnM




_______________________________________________
KDE PIM users mailing list
kdepim-users@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users


[prev in list] [next in list] [prev in thread] [next in thread]