Hello Mike,
Thursday, October 20, 2005, 1:23:12 PM, you wrote:
> The capability to view images doe not create a security hole. What
> the user does with that capability is the actual security risk.
Sorry, I got sucked into using the "security hole" term when what
we were originally debating was the SPAM aspect (webbugs), and you're
right, it's all based on the user and what they know. What I'm driving
at (see how witty I am by relating it back to the car thingy? <grin>)
is that RITLabs compromised with the HTML aspect by giving you the
ability to double-click the attached HTML file in order to see the
e-mail as it was intended by the sender. A double-click, two quick
clicks and you have the ability to see the HTML message in all its
blazing glory. Still a risk, but a conscious risk. You actually have
to do something, albeit a very insignificant something, by
double-clicking the HTML attachment. The functionality is there. You
can get exactly what you want by just a tiny, simple, little
double-click. Granted if your web browser isn't open, you'll have to
wait for it to load, but geez.
> Again, what about embedded links? These are a greater threat than
> say an embedded web bug. Click on the wrong link and you go straight
> to Java Script/ActiveX hell, yet these are not blocked. I respect
> anyone who is computer security aware, makes my job easier. Computer
> security is making me a lot of $$$$.
But the security issues are now being handled by an application
designed to view and deal with that content. Unfortunately for the
masses this means IE. But browsers were designed to view HTML, keep up
with all the standards (W3C, Section 508, WCAG, Javascript, DHTML
etc). That's why they exist. TB exists to send, receive and manage
e-mail. I just don't understand why people can't accept that RITLabs
compromised by giving you the HTML attachment to click on while still
maintaining the integrity of TB, and that a single double-click gets
you what you need.
> I highly doubt people have called their financial institutions
> demanding HTML mail.
Wells Fargo said they were now offering HTML e-mail due to customer
request. That was a couple years back.
> It is simply a part of the business model in corporate America. In
> my work, I have approached businesses about killing the HTML and
> embedded images or at a minimum, using a plain text option. The
> answer is a flat "no", it is not competitive. They consider it
> advertising and a matter of "keeping up with the Joneses". I have a
> Web designer friend who gets paid 6 figures to design HTML mail
> (newsletters, statements etc) for a large financial institution,
> they take this stuff seriously.
The businesses can send it all they want. If I want to see it, it's
just a single double-click away. If even that is too much, I can
download and install numerous other mail clients that will show me the
HTML message without that hefty double-click. If the ability to view
an HTML e-mail is of such profound importance (more so than filtering,
templates, and other management features) then why use TB. There are
so many others that offer the HTML feature you need, and they're free
to boot.
> Given the number of banks in the US, someone would have to
> specifically know what bank I am using and know the specific e-mail
> address for the e-mail that is being sent. One of my banks uses no
> less than 8 e-mail addresses (one for my savings statement, one for
> checking etc).
Yes, banks were a bad example, I was just trying to stick with the
example. Paypal, Amazon, Techtarget, Yahoo, MSN whatever. Pick your
poison. The point is that address based whitelists are flawed.
> Add that to complexity of munging the e-mail address
That one is a piece of cake.
> and duplicating the e-mail itself plus the actual return value of
> all this work = long shot.
And that's all spammers need to work with. They send a million e-mail
in the hope that just a few will respond. Same with phishing scams.
All it takes is just one to make the inconsequential cost of sending
the e-mail to make it worthwhile.
> That and my firewall blocks Port 80 in my mail clients, I have to
> specifically authorize a connection to a Web address. It's a pain,
> but it's necessary.
There you go!!! You have the knowledge and the resources to protect
yourself and do it even though it's a PITA. The masses do not and
would not because they don't understand and maybe don't even care.
With TB, if they want to double-click the HTML attachment so they can
see the purty pictures, they have all the power in their
double-clicking finger to do it, and if they get hosed over in the
process, it's because of their browser, not TB.
> I was being sarcastic, but since you brought it up. Yes, RIT Labs
> (and Poco Systems) did the right thing and reinvented the wheel.
> This is double duty, creating an e-mail client and Web browser/HTML
> editor at the same time. It is a lot of work for the few, but it
> does keep the rest of safe from that flawed IE engine.
I know you were being sarcastic, but I figured what the heck. In for a
pound, in for a dollar. <grin>
RITLabs even announced at one point that they were going to develop a
browser. Outlook/Express has IE, Thunderbird has Mozilla, M2 has
Opera etc. Mostly everybody else hooks into IE. The point being that
RITLabs cares enough about standing by their statement of creating a
secure e-mail client that they couldn't justify not re-inventing the
wheel. And to do that took time away from the development of TB as a
mailer.
--
TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x6C0AB16B
__ ____ ____ ____ Geocaching: http://gps.PCWize.com
( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp
)(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat
(____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org
Shh! I'm cleverly disguised as a responsible adult.
________________________________________________________
Current beta is 3.61.13 (Echo) | 'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
IMPORTANT: To register as a Beta tester, use this link first -
http://www.ritlabs.com/en/partners/testers/
