Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Your dissecting my personal experience which makes all your points, while valid, moot for my experience. :-) Tilman Schmidt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.04.2008 16:30 schrieb Michael Brown: The | character is not allowed in any e-mail address because it's a Unix shell reserved character. RFC 2822 disagrees with you. To begin with, there's no reason reserved characters of any Unix shell or other program should be disallowed in E-mail addresses. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 23. DEL Ok. These are indeed illegal by the RFCs. 2. Space Not true. Valid E-mail addresses containing spaces do exist, although their owners may have a hard time getting mails from some parts of the 'net. 3. ! 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] Ok in a way. These are special characters for the mail transport itself (as opposed to some application program or shell) - though only historically in the case of the exclamation mark - and are therefore better avoided. Mail addresses containing one of these in the local part (ie. before the last @) will indeed rarely go through. 4. Not true. In fact, any mail server I know of accepts mail addresses whose local part is enclosed in double quotes just fine. 5. # 6. $ 7. % 8. 12. , 13. / 14. : 15. ; Not true. I have already seen every one of these characters in valid E-mail addresses in the wild, and blocking them does generate complaints. (btdt) 9. ( 10. ) 11. * 22. | Not true either. While these are indeed rare, and may cause problems with buggy and/or misconfigured mail software, they are legal by RFC 2822, and blocking them is a policy decision which is far from unanimity. There are many mailservers which will indeed accept these. So why am I dissecting that list like this? Just to show that blocking or not blocking certain unusal characters in mail addresses is indeed a policy decision which should not be forced by a piece of software, but at most offered as a configurable option. HTH T. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3rc1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBTZlQ3+did9BuFsRAghXAKCYhBT45TH06hR8DWrB46WnzjDLpACglrgK MF3dKKZBUSnc+AmkDSg78z0= =BX/w -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
The | character is not allowed in any e-mail address because it's a Unix shell reserved character. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 2. Space 3. ! 4. 5. # 6. $ 7. % 8. 9. ( 10. ) 11. * 12. , 13. / 14. : 15. ; 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] 22. | 23. DEL Bas van Rooijen wrote: ClamAV is rejecting messages where the recipient address contains a | (pipe character).. Why is this? Is | a virus now? Can this behaviour be disabled? Are you planning on blocking other random characters from appearing in the recipient adres? thanks, bvr. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] US-CERT alert regarding ClamAV
Any links to the real full report, all I found was don't scan PE files ? Gerard wrote: I just received an alert from US-CERT regarding ClamAV. The full report is available here: http://www.us-cert.gov/current/index.html#clamav_pe_scanning_vulnerability ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Instability and Modern Anti-Virus Software
ClamAV's strong point for me, has always been the ability to turn off just about anything causing an issue. I haven't seen this kind of fine detail ability in any AV product (commercial or free) that can match ClamAV for flexibility. In theory, anything can mess up an AV package. ClamAV had a issue a while back with bad updates that would crash ClamAV daemon, so yes I guess technically that could be counted as an instability, even if it really had nothing to do with the actual definitions or data. Reading the list, I see a lot of talk about the URL phishing scanning causing some slow scans, but again, this can be turned off if it's causing a problem. Overall, most of the commercial AV products are set it and forget it, which I think is never a good thing for a system admin if something goes wrong, you have no idea where to start. At least with ClamAV if something is killing the AV product (some weird Rar files, etc.) it can be turned off until a solution is found. That's why I would prefer ClamAV to others, I can see what the heck is going on and can talk with others here about the same issue without all the product red tape as I could call it. But to answer you question, yes those signature updates can cause serious scanning issues or false positives, it's just the nature of the beast and how you word semantics to define what serious scanning issues and false positives are. It's impossible to code an infallible AV scanning engine. Thanks, Michael Paul Kosinski wrote: There is an article on eWeek.com today concerning instability in AV software due to the impossibility of adequately testing updates when releasing them as quickly as they are needed (www.eweek.com/article2/0,1895,2240656,00.asp?kc=EWKNLINF010208STR3). As I understand it, ClamAV is perhaps unusual in that CVD updates are purely data and do not change the executable code, so instability is much less likely. On the other hand, perhaps some signature data, especially those pertaining to phishing, contain something like counts governing FOR loops, or worse yet, termination conditions governing WHILE loops. In these cases, scanning could take a long time -- or even forever -- if there were a bug. An even worse case would be a update with a bad data-length field, or an improperly terminated string, either of which could cause a crash. So my question is, do ClamAV signature updates have the potential to cause serious scanning problems, or is it limited to lesser problems like false positives? (Of course, all AV scanners are prone to false negatives on recent, or cleverly obfuscated, viruses.) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] I need to refute a 'security expert'
Well 'security expert' is just a title. Heck, anyone can call themselves a security expert and if you just need another security expert to refute his/her claim personally with some marketing jargon to do with it, I'm sure anyone here would volunteer, in absence of that I will volunteer as a security expert if need be. The last major AV test I read about had ClamAV at the top of all over commercial or free virus scanners out there. This was only a month or so ago from what I remember. I'm sure these studies and test are all over Google/Yahoo/Ask, etc search engines. Of course, the big thing is, what are they selling and what are they comparing ClamAV to? Thanks, Michael [EMAIL PROTECTED] wrote: Hello all. We've had some consultant make the spurious claim that Clam AV only scans for 'windows viruses' and is really only useful for 'scanning email'. Despite the fact that I know this to be patently false, is there documentation out there I can slap him with that clearly indicates that the virus defs are for any platform, Linux, windows, Unix, Mac OS X, etc. ? I can prove that it scans the file system just by sprinkling a few test viri things out in the file system. Hard to argue with that sort of evidence. The rest of it, well, now it's personal. -J ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Vote for ClamAV as the best anti-malware solution
I used a junk e-mail account, they only use the e-mail for vote verification. So far, no spam. If I get any before the voting closes, I'll report it back. Thanks, Michael Dean Brunson wrote: I went there to cast a vote, too. I couldn't find any statement of how they would use my e-mail address. I closed the window without voting. Chuck Swiger wrote: On Oct 23, 2007, at 8:32 AM, Mike Guiterman wrote: ClamAV has been nominated for the Best Anti-Malware Solution in the 2008 SC Magazine Readers Trust Awards. Please vote using the link below to make sure that ClamAV is recognized as the best anti-malware solution. These awards recognize the hard work of the ClamAV team and community contributions to the ongoing development of ClamAV and the signature database. http://www.scmagazine.com/us/awards/categories/26137/best-anti- malware-solution/ While this might be a nice idea, an attempt to vote takes one to a registration page with a captcha, which is almost immediately covered up by a huge panel of sponsored links which makes it impossible to actually cast a vote. So much for HMTL design... ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] looking for a stream of messages for testing purposes
I have about 82 messages of virus, spam, scams, and the like. I clean out the virus e-mail holding account about every year, if you had caught me sooner I would have close to 50,000 for you, but I hope 82 can do for now. Thanks, Michael Jeff Donsbach wrote: On 4/13/07, I wrote: [I tried asking this on the developer's mailing list, but posting is restricted there, so] I am looking to do some performance testing of ClamAV in various configurations on various hardware. I am wondering if you have a stash of email messages, with at least some malware infected, that you use for your own testing and if so, could I get a copy of it? Btw, I'll be happy to share my results. I have to write up a presentation on what I find. Thanks in advance for any pointers. Anyone? Devs? Isn't there something you guys use for QA? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Clamav suddenly died on several boxes
I can verify this worked for me as well. Wipe the database, let freshclam update again, restart the clamd process and everything was running smooth again. Thanks, Michael James Kosin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, Deleting the database directory and restarting freshclam to get the databases again seems to have fixed the problem on both systems. This problem may be related to getting incremental updates and not being able to update the .CVD database properly. This is the only clue I can give. - -James -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHObJkNLDmnu1kSkRAgHYAJ9Fr2zUdedPA9RUXUxBMx8Vu4zQ9gCdE/cs T+OJjNC65ht0Yi63uwCWKLc= =HHqU -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Problem with big mails
I have to agree, in the technical sense that if you allow larger attachments it really starts to sap the resources. I originally allowed 400MB attachment scanning and it would really load down the server at times. I set it back to default setting of 10MB and resource usage was much better. I figured like you, that most of the virus out there come in small packages. Any larger and the virus writer couldn't spread the virus because the huge files would clog up all the e-mail servers. Unless that was the intention to begin with, in which case clamav would still move along, just a lot of virus would be ignored, but all the others would be caught. Better to have to deal with 1 big virus than the other 100 little ones out there. Michael Chuck Swiger wrote: It's certainly possible for a large Word/Excel/whatever file to be infected, but they aren't very common. Out of the 400+ viruses quarantined over the past week or so on one of my mail servers, the average size was 11KB, and the largest malicious email was 116KB (it contained Worm.Bagle.pwd-eml). ---Chuck ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamscan-procfilter.pl stops working after upgrade to 0.9X clamav
Hi Everyone, I'm new to this list, but a long time user of ClamAV. For years I've been using this simple procmail (clamscan-procfilter.pl) script from http://www.virtualblueness.net/~blueness/clamscan-procfilter/ It's worked great, until I upgraded to the 0.9X ClamAV and it no longer is able to pass e-mails to the clamav daemon. I'm not sure why, but as far as I can tell everything is peachy with clamav, freshclam runs just fine, the clamd process is running. The configuration file is correct. The only thing I can guess (and after searching the mail list since no one else has reported this yet) is maybe some scanning parameters for the new clamav has changed and that's why this script is not working. The script has a section where it passes the e-mail to the clamdscan script to scan and then later in the file does other things to redirect virus infected e-mails, etc. As far as I can tell, the files are being sent over to scan, but they remain (never removed after a successful scan). I thought maybe this is not using the right command to scan the file (updated version has new parameters) and thus that's why e-mails are not getting a proper clamav scan. If anyone has experience with this procmail script, any information would be greatly appreciated. # Where are your binaries? # $MKTEMP='/bin/mktemp' ; $CLAMSCAN='/usr/bin/clamdscan' ; $FORMAIL='/usr/bin/formail' ; # # Read in the email from stdin # @file = ; # # Create/open a temp file for the output of clamscan # $TMPFILE=`$MKTEMP /tmp/clamtemp.XX` ; chomp $TMPFILE ; open CLAM, |$CLAMSCAN --stdout --mbox - $TMPFILE ; print CLAM @file ; close CLAM ; Thanks, Michael ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamscan-procfilter.pl stops working after upgrade to 0.9X clamav
Jim Maul wrote: Im not running 0.9X but im pretty sure --mbox isnt valid anymore. And why is the variable CLAMSCAN when its calling clamDscan? Its just a little confusing... Wow, you guys are amazing, that's exactly what it was! I removed the --mbox and everything works again!! The Clamscan is just a variable that the original script author wrote so that people could plug in the script locations (it was using the clamscan, I changed mine to use the clamdscan for faster scanning), in mine for example. It's been working for so many years without problems, one loses track of it until they upgrade to the latest builds and it no longer works, LOL. Just so for future people in case they run into this issue like I did. In the script clamscan-procfilter.pl look for open CLAM, |$CLAMSCAN --stdout --mbox - $TMPFILE ; and change it to (remove the --mbox since it's no longer valid) open CLAM, |$CLAMSCAN --stdout - $TMPFILE ; Save your file and you are good to go. Thanks to Jim Maul for pointing this out, saved me hours of trying to find the solution on the web! Thanks, Michael ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
