On Nov 15, 2004, at 8:26 AM, jef moskot wrote:
On Mon, 15 Nov 2004, Trog wrote:For example, the last Bagle (or Bofra) outbreak simply sent an email to
it's target victims, who then have to click on a link to download the
Worm. According to your definition, that is a 'social' attack, and
should not be blocked.
I was going to make this same point.
I understand what Julian is trying to say, and I don't object to a ClamAV
option that would allow him to receive all the unwanted garbage he wants,
but I don't really buy his logic.
He says some people might want to receive 419 scams and such, but some
people might also want to receive viruses. Sys admins often make the call
that people can't have free access to viruses, for the good of the
community, and I see granting people easy access to spread malware (either
accidentally or purposely) or encourage phishing falling into the same
category.
It becomes a question of degree, though. Yes, it's harmful if you're dumb enough to give your life's savings to a stranger in another country. It's stupid to buy p3n1s enhancements from UBE. But we can't protect users from every single scam out there. There's already programs that administrators can use to try to fight that available, and they have quite a bit of lead time on ClamAV in that respect. It's a whole other fight...you can protect users from binary attachments of malware, but you can't protect them from stupidity. I'd say leave it to the antispammers to hammer out, and to the people who focus on bayes filters...let the Clam team focus on analyzing the latest binaries floating around out there.
The binaries are one thing...it's easier to find those attachments and create sigs for them. If it were easy to break spam and assorted click-here-for-her-pleasure mails into signatures I'm sure SpamAssassin and it's brethren would have stamped out the bulk mail business a long time ago. At least with viruses, the Clam team can stamp them out as they crawl from the woodwork while spam is more like a bottomless can of prank peanut brittle. The spam just keeps coming no matter what defense is put in place.
I appreciate the intellectual argument that ClamAV should remain "modular", but in basic practice, anyone who is preventing users from receiving all the viruses their inboxes can handle isn't doing them a disservice by closing off another malware avenue.
May be doing them a disservice if the signature mismatch a legit mail, though. Or introduce more bugs because the coding for the scanning engine gets more complex. The tools are out there already to fight spam, it may be better to support their efforts instead of bolting more functionality to ClamAV. Bolting more functions to a program, extending it beyond the original design, is a good way to start introducing problems and losing focus of the project.
I'd beg people who want more anti-phishing/spam functions to instead support the teams that are already waging that war...contribute recipes and code to the SpamAssassin teams or another OSS filtering team. Make ClamAV the best virus blocker available for working *with* those programs to provide a solid anti-malware platform.
Personally, I don't think much of SpamCop, but I do see that as Julian's
most compelling argument. I think that warrants a ClamAV option, but I
also think it would be ill-advised to use it.
I think a lot of the the proposal should probably be tabled unless the core Clam team expresses an interest in tackling this type of direction, and also could provide some tests to show how accurate it is...how much benefit there is to doing it this way versus how much of a system cost it would impose (database size, scan time, etc.)...keeping in mind that some people also use Clam to scan files on a hard drive. Why add scanning for phishing attacks on a .doc file saved in my file share? If you want to allow classification of code as phishing vs. virus vs. social engineering, how will this impact the team's time efforts and efficiency of scanning files on the hard disk? It would be nice to know just what kind of a performance hit this will introduce, especially after the recent discussions on new ways to ease the load on the servers for downloading signatures and distributing update notices via DNS servers...how big will the database get if there is a "spam signature repository" added?
Most solutions that I've found on the Internet for ClamAV scanning mail already include spam filtering and spam scanning via another OSS project...Amavisd-New expects that separation of virus vs. spam functionality precisely because it fights with different methods and spammers are notoriously clever at circumventing signatures.
-Bart
_______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
