On Freitag, 14. Juni 2013 22:12:42 CEST, David Lang wrote:
repeated scary warnings are worse than useless. They
desensitize users about other, more important, warnings.
I did not seriously suggest that as viable option (the workflow alone would be
nasty)
You cannot protect all the users. If you try you will just make
the software worthless.
I can not protect a single one.
That does not mean one should encourage them to jump off the cliff.
and to be realistic, most images are not actually attacks
Most images i get are actually attached, probably because MUAs don't make it
particularily easy to embed an external image, so ppl. rather send the link than some
<img> tag. Those are usually automated mails and the majority of them i would
consider spam (whether the images are inteded as verification i can't say, probably
not all of them)
If you want to have some sophisticated approach to block
images, make a plugin interface for it and let people use
spamassasin, blacklists, etc to block things.
SA blocking would block spam - the problem is if mails make it through and then SA
had to edit the mail to strip <img> tags sourcing untrusted domains.
require manual opening of images
usual hostile environment
auto open all images
friendly environment
auto open only if on 'cheap' Internet connection
should probably happen anyway (whether expensive or slow)
On Freitag, 14. Juni 2013 23:32:31 CEST, Jan Kundrát wrote:
On Friday, 14 June 2013 22:12:42 CEST, David Lang wrote:
_possibly_ override the default on a per-folder basis
I don't think that the folder-based policy is particularly safe
-- it would be trivial to defeat any of my filters
It would only make sense for a user managed mailbox (ie. some box where you
drag mails by hand)
Otherwise it's indeed as unreliable as relying on the sender.
And if you just block all images, you end up not protecting the
users anyway as they will move to a mail client that will let
them see the kitten pictures that people send to them without
such horrid annoyances.
Just to avoid misunderstandings:
this is not about blocking image attachments (that's not a MUAs job at all) or
rendering attached images inline with textmails, but fetching and rendering
images with html mails that are *not* attached to the mail but reside on
foreign domains.
An image attached to the mail resides at your MSP - it's too late, they already
know you fetched the mail ;-)
Cheers,
Thomas
