Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter wrote: Quoting John Rudd [EMAIL PROTECTED]: Tilman Schmidt wrote: 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. Absolutely agree. I disagree in this case (read on). It is not ClamAV's place to make policy decisions for me. And ClamAV does not. The milter is. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. It does not. What leaves an exploitable sendmail is a poorly configured sendmail. The problem is already fixed, and properly fixed, in sendmail's own configs. This makes it the wrong tool for the job. Adding this to the milter is adding code to fix something that isn't broken. It is never good to be the wrong tool for the job, nor fixing something that isn't broken. And, therefore, it is doubly bad to be both. Further, it imposes this fix upon mailers that don't have a vulnerability (keeping in mind that other MTAs can use milters now). That's three strikes*. (* yes, I know most of the readers here might not be in the US, nor familiar with baseball metaphors, but hopefully they'll get that three strikes is a threshold of disqualification) I'm not saying it can't be configurable, but whether it is or not, it must be disabled by default, IIF it is known to make sendmail or the milter itself exploitable. That would be true if and only if the proper fix didn't already exist within sendmail itself. (and I don't recall if it's the default in sendmail, or not ... but that doesn't matter, because the PROPER FIX is to use the sendmail config which stops the exploit ... that proper fix might be as simple as do nothing, if it IS the default) At most, it should offer me policy options, but only _options_. You would rather it allows you to become exploitable? I wouldn't... Nice strawman. No, I wouldn't like to be exploitable. And, without this feature, I wouldn't be (not even if I was running sendmail), because the fix already exists within its proper location (within sendmail itself). IMHO, the proper thing to do is to document this in the milter docs. Whether it becomes a configurable option or not, it should certainly be documented that the default is to block such addresses. No, the proper thing to do is not fix things that aren't broken. This is already fixed in the proper place. At the most, the ClamAV team, and/or the clamav-milter team, should provide a STRONG recommendation that the sendmail config should use its existing technique for fixing the problem (which may be as simple as do nothing except don't overide the default). BUT, the point of my email is ClamAV is an anti-virus program, its jobs is to match patterns and report the match. clamav-milter is a separate program, a milter for sendmail. A milter is by definition a filter. It's job IS to filter (see: https://www.sendmail.org/milter/), even though many people use them in a non-filtering way... Don't confuse the two programs, or their functions. Close, but not correct. Milters in general exist to provide general filtering capability. The clamav-milter is not a general milter. It's a specific milter, whose specific purpose is to provide ClamAV capability via the milter interface. Your argument here would be valid if the clamav-milter were a general purpose milter, such as MIME-Defang. Or if it were a special purpose milter whose special purpose wasn't specifically providing ClamAV via the milter interface. Again, it is providing a fix in the wrong location, and fixing something that isn't broken. It would be irresponsible for a milter to knowingly allow a security hole by default. Incorrect. It is irresponsible for a milter to allow a security hole IN THE AREA THAT THE MILTER ADDRESSES. The clamav-milter isn't a general security tool, it is a _ClamAV_ milter. By your logic, EVERY milter on the planet should waste its time doing EVERY security check known in order to be sure that not only is sendmail not mis-configured, but neither is every other milter in use. That's wasteful, poorly conceived, and just a plain bad idea. Use the right tool for the job. Fix the problem where the problem exists. The right tool for the job is the existing sendmail fix for the problem. The proper location of the fix is within the sendmail configuration. Not in EVERY milter on the system. Not in ANY milter on the system. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. No, it is not. The best protection for that hole already exists within sendmail. Fixing it within the clamav-milter is _STUPID_. ___ Help us
Re: [Clamav-users] US-CERT alert regarding ClamAV
James Brown wrote: On 16/04/2008, at 4:33 AM, fchan wrote: This part of clamav-0.92 and new fix of a bug. https://wwws.clamav.net/bugzilla/show_bug.cgi?id=613 And in short we need to get gcc4.1.1 or newer to get this work on Macintosh 10.4.11 and xcode 2.5 which only has an gcc 4.0.1. However Apple hasn't released gcc 4.1.1 or newer for the Mac 10.4.11 so we are left to use this an workaround for this an Japanese clamav user found this and here is the workaround: export CFLAGS='-g' -g means debug mode building. Then configure and make as you have done before. I hope this helps. Frank John Rudd wrote: Oh, and, while we're on the subject, what about 0.88.6? is that version vulnerable? (don't tell me to upgrade -- I haven't been able to get newer versions to compile on Mac OS X 10.4.x) Frank John, I've used ./configure --enable-experimental CFLAGS=-O0 to get ClamAV (including 0.93 yesterday) to compile on Intel Macs (as have others). I'll check to see if it works on a PPC mac (I don't have a Intel Mac). ___ 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
Eric Rostetter schrieb: Quoting John Rudd [EMAIL PROTECTED]: It is not ClamAV's place to make policy decisions for me. And ClamAV does not. The milter is. That distinction is immaterial. The milter comes as part of the ClamAV package. s/ClamAV/clamav-milter/ throughout my posting if you want, it doesn't change my argument in any way. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. The premise of this implication is false, therefore the conclusion doesn't follow. Passing E-mail addresses containing shell metacharacters does not produce an exploitable sendmail. It is ClamAV's place to match email messages to signatures. Yes, but this is _not_ the function of the milter, it is the function of ClamAV, and ClamAV is not the thing causing the issue, the milter is. Ok, since a simple s/ClamAV/clamav-milter/ probably won't cut it in this case, I'll rephrase that statement: It is clamav-milter's place to pass messages to clamd for matching them to signatures. At most, it should offer me policy options, but only _options_. You would rather it allows you to become exploitable? I wouldn't... Most programs allow you to become exploitable. It is always up to you to configure them so that this doesn't happen. Programs that *make* you exploitable are the problem, but a hypothetical clamav-milter that wouldn't block mail addresses containing vertical bar or semicolon characters does not fall into that category. IMHO, the proper thing to do is to document this in the milter docs. Whether it becomes a configurable option or not, it should certainly be documented that the default is to block such addresses. That would have been the minimum. But it is still wrong for a milter whose advertised purpose is to pass messages to a virus scanner, to start blocking messages based on unrelated criteria like allegedly illegal characters in addresses. BUT, the point of my email is ClamAV is an anti-virus program, its jobs is to match patterns and report the match. clamav-milter is a separate program, a milter for sendmail. A milter is by definition a filter. It's job IS to filter (see: https://www.sendmail.org/milter/), even though many people use them in a non-filtering way... Don't confuse the two programs, or their functions. Ok, point taken. Consider them unconfused. Now please let us discuss the clamav-milter program, distributed with ClamAV but separate from it, and how it should behave with respect to the recipient addresses of the mails it processes. My position is still that checking the legality of those is not its job and it should leave them alone. It would be irresponsible for a milter to knowingly allow a security hole by default. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. Clamav-milter cannot protect my mail server against all possible security holes, and shouldn't even try. It has a precise job, which is to check mails for known viruses by passing them to ClamAV, and block their delivery if the check comes back positive. Other security risks must be covered by other means. Thanks, Tilman signature.asc Description: OpenPGP digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Known viruses count suddenly droped
Thanks for solving out mystery for me :) Looks like you might have been loading one of the tables twice. dp -- Regards, Noor Ahmed Afridi ___ 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
John Rudd wrote: It is never good to be the wrong tool for the job, nor fixing something that isn't broken. And, therefore, it is doubly bad to be both. In general: DO NOT HARDCODE POLICY Otherwise, your tool becomes irritating or possibly even harmful. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Can clamav-milter quarantine ALL messages?
Thanks, Michael. I didn't see QUARANTINE as a access file option in the man pages. I will try that. Thanks again! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Isaev Sent: Wednesday, April 16, 2008 11:30 PM To: ClamAV users ML Subject: Re: [Clamav-users] Can clamav-milter quarantine ALL messages? Can I either(thru sendmail, clamav, or clamav-milter): Quarantine all messages from a particular IP ? You can (thru sendmail). Append 'access' file from sendmail as follow: Connect:aaa.bbb.ccc.dddtabQUARANTINE Michael ___ 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] (no subject)
Hello, I'm trying to add some values to whitelist following phishsigs_howto.pdf doc. It's a simple conf, but it doesn't work. With 'clamscan --debug email.file' command capture: LibClamAV debug: Phishcheck:Checking url http://ad.doubleclick.net/clk;77451406;6134080;d?http://www.correo.movistar.es/do/isp/assistant/login?isp=terra -aquiacute;. LibClamAV debug: Phishcheck:URL after cleanup: http://ad.doubleclick.net/-aquiacute LibClamAV debug: Displayed 'url' is not url:aquiacute LibClamAV debug: Phishcheck: Phishing scan result: Clean LibClamAV debug: blobDestroy 1 LibClamAV debug: blobDestroy 1 LibClamAV debug: messageAddArgument, arg='filename=mixedtextportion' LibClamAV debug: messageToFileblob LibClamAV debug: blobCreate LibClamAV debug: messageExport: numberOfEncTypes == 1 LibClamAV debug: messageExport: enctype 0 is 1 LibClamAV debug: messageFindArgument: compare 8 bytes of filename with name=attachment LibClamAV debug: messageFindArgument: compare 8 bytes of filename with filename=mixedtextportion LibClamAV debug: blobSetFilename: mixedtextportion LibClamAV debug: fileblobSetFilename: mkstemp(/tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionXX) LibClamAV debug: Creating /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: Exported 2895 bytes using enctype 1 LibClamAV debug: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX is infected LibClamAV debug: fileblobDestructiveDestroy: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: The message has 0 parts LibClamAV debug: cli_mbox returning 1 /tmp/email.file: Email.Phishing.RB-2924 FOUND LibClamAV debug: Cleaning up phishcheck LibClamAV debug: Freeing phishcheck struct LibClamAV debug: Phishcheck cleaned up It's clean?? but command return 'Email.Phishing.RB-2924 FOUND', why? and I added this value to daily.wdb: M:http://ad.doubleclick.net/:aquiacutehttp://ad.doubleclick.net/:aqu%C3%AD What's wrong? Thanks in advance Jordi ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] phising whitelist
Hello, I'm trying to add some values to whitelist following phishsigs_howto.pdf doc. It's a simple conf, but it doesn't work. With 'clamscan --debug email.file' command capture: LibClamAV debug: Phishcheck:Checking url http://ad.doubleclick.net/clk;77451406;6134080;d?http://www.correo.movistar.es/do/isp/assistant/login?isp=terra -aquiacute;. LibClamAV debug: Phishcheck:URL after cleanup: http://ad.doubleclick.net/-aquiacute LibClamAV debug: Displayed 'url' is not url:aquiacute LibClamAV debug: Phishcheck: Phishing scan result: Clean LibClamAV debug: blobDestroy 1 LibClamAV debug: blobDestroy 1 LibClamAV debug: messageAddArgument, arg='filename=mixedtextportion' LibClamAV debug: messageToFileblob LibClamAV debug: blobCreate LibClamAV debug: messageExport: numberOfEncTypes == 1 LibClamAV debug: messageExport: enctype 0 is 1 LibClamAV debug: messageFindArgument: compare 8 bytes of filename with name=attachment LibClamAV debug: messageFindArgument: compare 8 bytes of filename with filename=mixedtextportion LibClamAV debug: blobSetFilename: mixedtextportion LibClamAV debug: fileblobSetFilename: mkstemp(/tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionXX) LibClamAV debug: Creating /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: Exported 2895 bytes using enctype 1 LibClamAV debug: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX is infected LibClamAV debug: fileblobDestructiveDestroy: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: The message has 0 parts LibClamAV debug: cli_mbox returning 1 /tmp/email.file: Email.Phishing.RB-2924 FOUND LibClamAV debug: Cleaning up phishcheck LibClamAV debug: Freeing phishcheck struct LibClamAV debug: Phishcheck cleaned up It's clean?? but command return 'Email.Phishing.RB-2924 FOUND', why? and I added this value to daily.wdb: M:http://ad.doubleclick.net/:aquiacutehttp://ad.doubleclick.net/:aqu%C3%AD What's wrong? Thanks in advance Jordi ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Clamdwatch.pl doesn't work after update from 0.92.1 to 0.93
Hi, Today I've updated my clamav from 0.92.1 to 0.93 (compiled in a redhat 5.1 server) Now my clamdwatch.pl script doesn't work. If I run it I get the following message: Clamd is in an unknown state. It returned: UNKNOWN COMMAND Any idea? I also attach my clamdwatch.pl Thanks -- --- Alessio Artini Sistema Informativo - Comune di Pontassieve Via Tanzini n.30, 50065 - Pontassieve (FI) Tel. +39 0558360258 - Fax +390558360285 Cell. +39 3315764255 [EMAIL PROTECTED] - www.comune.pontassieve.fi.it -- --- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] phising whitelist
jordi garcia wrote: Hello, I'm trying to add some values to whitelist following phishsigs_howto.pdf doc. It's a simple conf, but it doesn't work. With 'clamscan --debug email.file' command capture: LibClamAV debug: Phishcheck:Checking url http://ad.doubleclick.net/clk;77451406;6134080;d?http://www.correo.movistar.es/do/isp/assistant/login?isp=terra -aquiacute;. LibClamAV debug: Phishcheck:URL after cleanup: http://ad.doubleclick.net/-aquiacute LibClamAV debug: Displayed 'url' is not url:aquiacute LibClamAV debug: Phishcheck: Phishing scan result: Clean LibClamAV debug: blobDestroy 1 LibClamAV debug: blobDestroy 1 LibClamAV debug: messageAddArgument, arg='filename=mixedtextportion' LibClamAV debug: messageToFileblob LibClamAV debug: blobCreate LibClamAV debug: messageExport: numberOfEncTypes == 1 LibClamAV debug: messageExport: enctype 0 is 1 LibClamAV debug: messageFindArgument: compare 8 bytes of filename with name=attachment LibClamAV debug: messageFindArgument: compare 8 bytes of filename with filename=mixedtextportion LibClamAV debug: blobSetFilename: mixedtextportion LibClamAV debug: fileblobSetFilename: mkstemp(/tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionXX) LibClamAV debug: Creating /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: Exported 2895 bytes using enctype 1 LibClamAV debug: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX is infected LibClamAV debug: fileblobDestructiveDestroy: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: The message has 0 parts LibClamAV debug: cli_mbox returning 1 /tmp/email.file: Email.Phishing.RB-2924 FOUND LibClamAV debug: Cleaning up phishcheck LibClamAV debug: Freeing phishcheck struct LibClamAV debug: Phishcheck cleaned up It's clean?? but command return 'Email.Phishing.RB-2924 FOUND', why? and I added this value to daily.wdb: M:http://ad.doubleclick.net/:aquiacutehttp://ad.doubleclick.net/:aqu%C3%AD What's wrong? daily.wdb is for Phishing.Heuristics.* detection. Email.Phishing.* detection is done via signatures from the database. You need to add an entry to daily.fp to avoid the false positive. Or submit the sample as a false positive. Best regards, --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Clamdwatch.pl doesn't work after update from 0.92.1 to 0.93
Artini Alessio wrote: Hi, Today I've updated my clamav from 0.92.1 to 0.93 (compiled in a redhat 5.1 server) Now my clamdwatch.pl script doesn't work. If I run it I get the following message: Clamd is in an unknown state. It returned: UNKNOWN COMMAND Any idea? Replace RAWSCAN with SCAN. Best regards, --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Applications starting to drop clamav support due to license incompabilities
Some time ago (after 0.90.3) clamav changed its license, downgrading it from GPLv2 or later to GPLv2 only, thus making it incompatible with programs linking to libclamav and released under the GPLv3 or later, which are now being common. The first application to drop clamav support is the Claws Mail mail client: http://www.thewildbeast.co.uk/wordpress/2008/02/29/claws-mail-clamav-gplv2-gplv2-gplv3-and-the-clamav-plugin/ Others may follow. So, what's the real motivations for the downgrade from GPLv2 or later to GPLv2 only? Has clamav / SourceFire removed the or later clause because has plans to ask payment or sue its users for patent in the code (both forbidden by the GPLv3)? I hope no. Is there a future plan to restore the or later clause? Thanks, Fabio ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Clamdwatch.pl doesn't work after update from 0.92.1 to 0.93
Török Edwin wrote: Replace RAWSCAN with SCAN. It would be nice if the removal of RAWSCAN (1) were mentioned more prominently than a one-liner in Changelog, and (2) were removed from the docs at docs/html/node23.html Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] phising whitelist
Hello Edwin, how Can I add the entry to daily.fp or submit the sample? I read clamav man and didn't found any information about that. Kind regards Jordi 2008/4/17, Török Edwin [EMAIL PROTECTED]: jordi garcia wrote: Hello, I'm trying to add some values to whitelist following phishsigs_howto.pdf doc. It's a simple conf, but it doesn't work. With 'clamscan --debug email.file' command capture: LibClamAV debug: Phishcheck:Checking url http://ad.doubleclick.net/clk;77451406;6134080;d?http://www.correo.movistar.es/do/isp/assistant/login?isp=terra -aquiacute;. LibClamAV debug: Phishcheck:URL after cleanup: http://ad.doubleclick.net/-aquiacute LibClamAV debug: Displayed 'url' is not url:aquiacute LibClamAV debug: Phishcheck: Phishing scan result: Clean LibClamAV debug: blobDestroy 1 LibClamAV debug: blobDestroy 1 LibClamAV debug: messageAddArgument, arg='filename=mixedtextportion' LibClamAV debug: messageToFileblob LibClamAV debug: blobCreate LibClamAV debug: messageExport: numberOfEncTypes == 1 LibClamAV debug: messageExport: enctype 0 is 1 LibClamAV debug: messageFindArgument: compare 8 bytes of filename with name=attachment LibClamAV debug: messageFindArgument: compare 8 bytes of filename with filename=mixedtextportion LibClamAV debug: blobSetFilename: mixedtextportion LibClamAV debug: fileblobSetFilename: mkstemp(/tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionXX) LibClamAV debug: Creating /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: Exported 2895 bytes using enctype 1 LibClamAV debug: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX is infected LibClamAV debug: fileblobDestructiveDestroy: /tmp/clamav-a9869b35a7e918d7824ef5c965af32aa/mixedtextportionTu1XhX LibClamAV debug: The message has 0 parts LibClamAV debug: cli_mbox returning 1 /tmp/email.file: Email.Phishing.RB-2924 FOUND LibClamAV debug: Cleaning up phishcheck LibClamAV debug: Freeing phishcheck struct LibClamAV debug: Phishcheck cleaned up It's clean?? but command return 'Email.Phishing.RB-2924 FOUND', why? and I added this value to daily.wdb: M:http://ad.doubleclick.net/:aquiacute http://ad.doubleclick.net/:aqu%C3%AD What's wrong? daily.wdb is for Phishing.Heuristics.* detection. Email.Phishing.* detection is done via signatures from the database. You need to add an entry to daily.fp to avoid the false positive. Or submit the sample as a false positive. Best regards, --Edwin ___ 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] phising whitelist
jordi garcia wrote: Hello Edwin, how Can I add the entry to daily.fp See signatures.pdf 2.5 Whitelist databases. You can either put the md5 into a .fp file, or add an entry to local.ign. or submit the sample? I read clamav man and didn't found any information about that. Submit it here, make sure you mark it as a false positive: http://cgi.clamav.net/sendvirus.cgi Best regards, --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-milter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 17, 2008 at 12:03:42PM -0400, Jerry Ferguson wrote: Problem: clamav-milter loads and immediately terminates You gave lots of good build information, but didn't say how you were calling the milter itself. To give you something to compare to, here's how I call it on mine: # ps aux | grep clamav-milter | grep -v grep clamav 686 0.0 0.2 49760 1112 ?Ssl Apr13 0:27 clamav-milter --config-file=/etc/clamd.conf --max-children=20 --force-scan --quiet --external -ol local:/var/lib/clamav/clamav-milter.socket One really important thing is that the directory where it should write the socket must be writable by the user you're telling it to run as. If I had to lay money down, I would say that's what is wrong in your case. - -- Regards... Todd We should not be building surveillance technology into standards. Law enforcement was not supposed to be easy. Where it is easy, it's called a police state. -- Jeff Schiller on NANOG Linux kernel 2.6.22-14-generic 5 users, load average: 0.29, 0.14, 0.11 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIB3hiY2VBGxIDMLwRAgXeAJsHRaXob09z6JWXwxi107wImckpKwCfVHoI TZi4q/ZMyWZ1jr0tCLDTfUg= =8Pxv -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] phising whitelist
On Thu, Apr 17, 2008 at 06:52:12PM +0300, T?r?k Edwin wrote: ... In case other people missed it. From: jordi garcia [EMAIL PROTECTED] To:ClamAV users ML clamav-users@lists.clamav.net Subject: Re: [Clamav-users] phising whitelist Date: Thu, 17 Apr 2008 17:44:25 +0200 Contained: Email.Phishing.RB-2924 -- Kelsey Cummings - [EMAIL PROTECTED] sonic.net, inc. System Architect 2260 Apollo Way 707.522.1000 Santa Rosa, CA 95407 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Can clamav-milter quarantine ALL messages?
It seems like this is rejecting the mail with a 'reject=553 5.3.0 QUARANTINE' error instead of quarantining it to a folder. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gomes, Rich Sent: Thursday, April 17, 2008 9:03 AM To: ClamAV users ML Subject: Re: [Clamav-users] Can clamav-milter quarantine ALL messages? Thanks, Michael. I didn't see QUARANTINE as a access file option in the man pages. I will try that. Thanks again! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Isaev Sent: Wednesday, April 16, 2008 11:30 PM To: ClamAV users ML Subject: Re: [Clamav-users] Can clamav-milter quarantine ALL messages? Can I either(thru sendmail, clamav, or clamav-milter): Quarantine all messages from a particular IP ? You can (thru sendmail). Append 'access' file from sendmail as follow: Connect:aaa.bbb.ccc.dddtabQUARANTINE Michael ___ 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 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamav-milter
Problem: clamav-milter loads and immediately terminates You gave lots of good build information, but didn't say how you were calling the milter itself. To give you something to compare to, here's how I call it on mine: # ps aux | grep clamav-milter | grep -v grep clamav 686 0.0 0.2 49760 1112 ?Ssl Apr13 0:27 clamav-milter --config-file=/etc/clamd.conf --max-children=20 --force-scan --quiet --external -ol local:/var/lib/clamav/clamav-milter.socket One really important thing is that the directory where it should write the socket must be writable by the user you're telling it to run as. If I had to lay money down, I would say that's what is wrong in your case. my startup command is: mail# /usr/pkg/sbin/clamav-milter --external --max-children=10 \ --pidfile=/var/run/clamav/clamav-milter.pid \ --quarantine-dir=/var/run/clamav/quarantine local:/var/lib/clamav/clamav.sock mail# ps -ax | grep clam 636 ? IWs 0:00.01 /usr/pkg/bin/freshclam -d -c2 671 ? IWsa 0:03.88 /usr/pkg/sbin/spamass-milter -u clamav -p /var/run/spamass.sock -f 19645 ? Ssa 0:04.46 /usr/pkg/sbin/clamd the clamav.sock file is created but the clamav-milter has terminated. I am calling it from sendmail - also calling spamass-milter which is working from clamd.log: Thu Apr 17 14:44:03 2008 - Starting ClamAV version 0.93, clamav-milter version 0.93 _res is not supported for multi-threaded programs. What does the _res is not supported mean? Regards... Todd ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-milter
At 09:03 17-04-2008, Jerry Ferguson wrote: I have a Clamav-milter problem. Can anyone help? Problem: clamav-milter loads and immediately terminates Hardware: Computer processor is AMD, sata raid 1 software: NetBSD 4.0 (I386 platform) [snip] _res is not supported for multi-threaded programs. That's why the process exits. Multi-thread programs such as milters should not access _res like that if you have BIND9 libs. Are you using the version in pkgsrc? it contains the required patch. Regards, -sm ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] compiling on AIX 5.2 and location of libgmp.
This is version 4.2.2 of GMP, and it SEEMS to compile just fine; I can run make check with no errors. running nm /usr/local/lib/libgmp.a |grep __gmpz_init returns nothing; and then configuring clamav with either: LDFLAGS=-R/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/local/ssl ./configure --disable-static -ICONV_LIBS=-L/usr/lib/libiconv.a -liconv LIBCLAMAV_LIBS=-L/usr/local/lib -lz -lbz2 -lgmp -L/usr/lib/libiconv.a -liconv LIBS=-lnsl still result in clamav's configure choking with the ld: 0711-317 ERROR: Undefined symbol: .__gmpz_init ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. errors. I have to say, I'm totally stumped. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamav-milter
At 09:03 17-04-2008, Jerry Ferguson wrote: I have a Clamav-milter problem. Can anyone help? Problem: clamav-milter loads and immediately terminates Hardware: Computer processor is AMD, sata raid 1 software: NetBSD 4.0 (I386 platform) [snip] _res is not supported for multi-threaded programs. That's why the process exits. Multi-thread programs such as milters should not access _res like that if you have BIND9 libs. Are you using the version in pkgsrc? it contains the required patch. no, I downloaded and compiled from source which I have done since v 0.85 pkgsrc is version 92.1 which I will use for now. Thank you! Regards, -sm ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] compiling on AIX 5.2 and location of libgmp.
hmm. well. grepping for just mpz_init on libgmp.a also returns nothing. grepping for mpz_init in gmp.h returns: gmp.h: 0654-203 Specify an XCOFF object module. On Thu, Apr 17, 2008 at 2:40 PM, Török Edwin [EMAIL PROTECTED] wrote: Naomi Hospodarsky wrote: This is version 4.2.2 of GMP, and it SEEMS to compile just fine; I can run make check with no errors. running nm /usr/local/lib/libgmp.a |grep __gmpz_init Try grepping for just mpz_init. Also grep for mpz_init in gmp.h Best regards, --Edwin ___ 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] compiling on AIX 5.2 and location of libgmp.
Naomi Hospodarsky wrote: hmm. well. grepping for just mpz_init on libgmp.a also returns nothing. grepping for mpz_init in gmp.h returns: gmp.h: 0654-203 Specify an XCOFF object module. That string doesn't contain mpz_init, are you sure you used grep on gmp.h and not nm? This is weird. Please open a bugreport, and attach your gmp.h Also attach your tests/misc.c, and randmts.c, those seem to use mpz_init here. Best regards, --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-milter
At 12:41 17-04-2008, Jerry Ferguson wrote: no, I downloaded and compiled from source which I have done since v 0.85 pkgsrc is version 92.1 which I will use for now. pkgsrc contains version 0.93. Regards, -sm ___ 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
Quoting John Rudd [EMAIL PROTECTED]: And ClamAV does not. The milter is. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. It does not. What leaves an exploitable sendmail is a poorly configured sendmail. The problem is already fixed, and properly fixed, in sendmail's own configs. This makes it the wrong tool for the job. I don't know the history of this expliot, etc. So I can't comment on whether the fix should stay or not. It would depend on the default settings for sendmail, how long the fix has been in sendmail, how widely available the patched sendmail is today, etc. Adding this to the milter is adding code to fix something that isn't broken. I would assume it was added at a time when it was broken (or was broken in the default install, etc). You might argue that it is no longer needed and should be removed, but that is a different argument, and as stated above it depends on knowledge of the history of the problems, history which I don't know so I can't make an informed decision on the matter. Further, it imposes this fix upon mailers that don't have a vulnerability (keeping in mind that other MTAs can use milters now). If the milter is designed for sendmail (this one was, as all older ones were) then their first duty is to sendmail, not to others who later decide to use them... Also, there may be other mailers who use milters who are also vulnerable besides sendmail, etc. So I see this point as moot. I'm not saying it can't be configurable, but whether it is or not, it must be disabled by default, IIF it is known to make sendmail or the milter itself exploitable. That would be true if and only if the proper fix didn't already exist within sendmail itself. But, is it widely deployed? If not, then the removal now might be premature (though making it configurable would certainly be within reason in that case). There is a reason I used IIF and it is because I don't know the history well enough to make absolute statements the way you do (without anything but your opinions to back them up). (and I don't recall if it's the default in sendmail, or not ... but that doesn't matter, because the PROPER FIX is to use the sendmail config which stops the exploit ... that proper fix might be as simple as do nothing, if it IS the default) I beg to differ. If it isn't secure by default in sendmail, then it is reasonable for the milter to enforce it. (It is also reasonable for the milter to make it conditional, and/or for the milter to simply document the problem and warn users to fix their sendmail configurations). What is done it up to the author, not a particular end-user. (Though the author may find he has more end-users if he listens to their advice...) At most, it should offer me policy options, but only _options_. You would rather it allows you to become exploitable? I wouldn't... Nice strawman. Why thanks! :) No, I wouldn't like to be exploitable. And, without this feature, I wouldn't be (not even if I was running sendmail), because the fix already exists within its proper location (within sendmail itself). But only if it is implemented in sendmail, etc... And while you may be the perfect admin, many admins are not, and might overlook the problem and be exploitable because it. Or the fix in the milter might even have pre-dated the fix in sendmail, or the documentation in the sendmail docs on how to properly secure it, which would leave people vulnerable. Again, I don't know the history, so... At the most, the ClamAV team, and/or the clamav-milter team, should provide a STRONG recommendation that the sendmail config should use its existing technique for fixing the problem (which may be as simple as do nothing except don't overide the default). I agree that the above is a suitable thing to do (document the issue). But that assumes that it was fixed in sendmail before the code was added, and that if it was fixed later the team knew this and had time to go back and remove it and fix the docs, etc. Again, I don't know the history, so... Milters in general exist to provide general filtering capability. The clamav-milter is not a general milter. It's a specific milter, whose specific purpose is to provide ClamAV capability via the milter interface. Clamav-milter is a filter for sendmail(1) mail server. It uses a mail scanning engine built into clamd(8). Read into that what you like... Again, it is providing a fix in the wrong location, and fixing something that isn't broken. Again, I don't know the history, so I can't comment. It would be irresponsible for a milter to knowingly allow a security hole by default. Incorrect. It is irresponsible for a milter to allow a security hole IN THE AREA THAT THE MILTER ADDRESSES. I disagree. The keyword of course is knowingly. Your opinion may vary. The
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting Tilman Schmidt [EMAIL PROTECTED]: That distinction is immaterial. The milter comes as part of the ClamAV package. s/ClamAV/clamav-milter/ throughout my posting if you want, it doesn't change my argument in any way. I think it completely changes your argument. Had you done that in the first place, I never would have replied in fact. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. The premise of this implication is false, therefore the conclusion doesn't follow. Passing E-mail addresses containing shell metacharacters does not produce an exploitable sendmail. Okay, so poor wording on my part. Sorry. It is clamav-milter's place to pass messages to clamd for matching them to signatures. How about: It is clamav-milter's place to pass messages to clamd for matching them to signatures in a safe and secure manor. Most programs allow you to become exploitable. It is always up to you to configure them so that this doesn't happen. And if it is not possible to configure it to do so? IMHO, the proper thing to do is to document this in the milter docs. Whether it becomes a configurable option or not, it should certainly be documented that the default is to block such addresses. That would have been the minimum. Yes, I can agree with that. But it is still wrong for a milter whose advertised purpose is to pass messages to a virus scanner, to start blocking messages based on unrelated criteria like allegedly illegal characters in addresses. In that case, most all of the milters I have used or considered for use are wrong. So clamav-milter is at least in good company. :) Ok, point taken. Consider them unconfused. Now please let us discuss the clamav-milter program, distributed with ClamAV but separate from it, and how it should behave with respect to the recipient addresses of the mails it processes. My position is still that checking the legality of those is not its job and it should leave them alone. My opionion is that if possible, without causing harm, it should do as you say. If doing so causes harm, then it must work to remedy that somehow. It would be irresponsible for a milter to knowingly allow a security hole by default. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. Clamav-milter cannot protect my mail server against all possible security holes, and shouldn't even try. I only think there is an obligation if the problem is a known problem, and there is no other known fix. It has a precise job, which is to check mails for known viruses by passing them to ClamAV, and block their delivery if the check comes back positive. Other security risks must be covered by other means. Well, we disagree on that point. It is a security tool, and as such has an even greater burden to try to be as secure as possible. Even without that, all programs should strive to be as safe as possible, and to avoid known security issues. That is all they were trying to do: avoid a known security issue. Did they do that the best way possible? Probably not. But should they not have done anything at all? Certainly not! Thanks, Tilman -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ 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
Quoting David F. Skoll [EMAIL PROTECTED]: In general: DO NOT HARDCODE POLICY Otherwise, your tool becomes irritating or possibly even harmful. In general, don't distribute code that allows remote root exploit of systems. Otherwise, your tool becomes irritating or possibly even harmful. Regards, David. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamav 0.93 on some BSDs
I tried building and running clamav 0.93 on a handful of BSD systems, running clamd on TCP port 3310 and seeing if I can get it to do respond to STREAM commands (and do the correct thing with a few samples). Mostly I had success, but with one exception: FreeBSD 7.0 - builds and runs fine FreeBSD 6.3 - builds and runs and responds (minimal testing) FreeBSD 5.2 - builds and runs but does not respond (much). For kicks I also tried it on an ancient BSD/OS 4.2 (BSDi) system; it builds and runs fine there too. But it really isn't happy on the FreeBSD 5.2 system. It will start up and make its initial marks in the log, the same as on the other systems. Attempts to connect to it and send a PING packet are almost universally met with lack of response (connection accepted, no reply comes back). Every once in a great while, it will respond to PING immediately and properly with PONG; it seems to break out of whatever is holding it back for that occasion, and then it will go back into non-responsive mode again for a number of hours. There is nothing logged. I have yet to get it to respond to a STREAM command. 'top' shows the clamd process sitting in accept state. Another oddity is that a HUP signal doesn't wake it up; on the other systems, HUP results in a log entry saying that the log file has been reopened. Does anyone know what magic I might try on the FreeBSD 5.2 system? I really don't plan on running it there for long, but it seems like it would be nice to make it work. The previous version that I ran successfully there was 0.91.2 . mm ___ 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
Eric Rostetter wrote: Quoting David F. Skoll [EMAIL PROTECTED]: In general: DO NOT HARDCODE POLICY Otherwise, your tool becomes irritating or possibly even harmful. In general, don't distribute code that allows remote root exploit of systems. Otherwise, your tool becomes irritating or possibly even harmful. Yikes! I guess that rules out shipping a c compiler! (and a lot of other general purpose tools as well) Joe ___ 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
At 14:42 17-04-2008, Eric Rostetter wrote: I don't know the history of this expliot, etc. So I can't comment on whether the fix should stay or not. It would depend on the default settings for sendmail, how long the fix has been in sendmail, how widely available the patched sendmail is today, etc. Do you know which version of sendmail can be used with the milter? If the exploit is prior to that, then the fix may not be applicable. At 14:54 17-04-2008, Eric Rostetter wrote: Well, we disagree on that point. It is a security tool, and as such has an even greater burden to try to be as secure as possible. Even If you are using the milter as a security tool, you would have to do more filtering than what's currently implemented to prevent problems downstream. Regards, -sm ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamd SHUTDOWN command
When clamd is listening via TCPsocket it seems to be possible for any user to shut it down by sending SHUTDOWN using e.g. telnet clamdhost 3310 SHUTDOWN Can this behaviour be disabled or restricted? It would appear that this could be abused for a DOS attack against a clamav server. ___ 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
Quoting SM [EMAIL PROTECTED]: At 14:42 17-04-2008, Eric Rostetter wrote: I don't know the history of this expliot, etc. Do you know which version of sendmail can be used with the milter? If the exploit is prior to that, then the fix may not be applicable. I never argued otherwise. And no, as I've said, I don't know the history, so no I don't know the versions involved. And yes, I've used poor wording twice now. For all I know, from what _little_ I know, the problem is in the popen() call in the milter, and not in the sendmail at the other end at all. How would I know? I have not, and probably will not, take the time to investigate this. For the record: I don't agree with the solution either. But I certainly don't agree that they should have done nothing! Don't paint me as a supporter for the way it was done. I'd have done it differently. But I sure wouldn't leave it exploitable just because I was afraid of forcing policy on someone. (Yes, I would have documented it, but I wouldn't have just ignored the problem...) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] unsubscribe
- Robert Johnston Datajockeys, LLC ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Can clamav-milter quarantine ALL messages?
Gomes, Rich wrote: It seems like this is rejecting the mail with a 'reject=553 5.3.0 QUARANTINE' error instead of quarantining it to a folder. Yes, older versions of sendmail cannot quarantine the mail. QUARANTINE option appears in sendmail since V8.13 And some precise for access file: Connect:aaa.bbb.ccc.dddtabQUARANTINE:quarantine reason here Show quarantine queue: mailq -qQ Michael ___ 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
Eric Rostetter wrote: In general, don't distribute code that allows remote root exploit of systems. Sendmail doesn't allow remote exploit due to recipient addresses with funny characters in them. It certainly hasn't since Milter has been around, so fixing the problem in a milter is dumb. Otherwise, your tool becomes irritating or possibly even harmful. Using one tool to fix the deficiencies in another tool is bad security... oh... wait a minute... that's the basis of the entire virus-scanning industry. :-( How sad. Regards, David. ___ 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
Eric Rostetter wrote: For all I know, from what _little_ I know, the problem is in the popen() call in the milter, Yikes popen() In a piece of SECURITY software??? I'm very glad I've never used Clam's milter. Regards, David. ___ 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
Eric Rostetter wrote: Well, we disagree on that point. It is a security tool, and as such has an even greater burden to try to be as secure as possible. In order for a security tool to be as secure as possible, it first of all needs to adhere to this basic principle: The tool behaves as advertised. Unless the behaviour with weird recipient addresses was prominently advertised, then it's surprising behaviour, and surprising behaviour is the enemy of security. Regards, David. ___ 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
Quoting David F. Skoll [EMAIL PROTECTED]: Unless the behaviour with weird recipient addresses was prominently advertised, then it's surprising behaviour, and surprising behaviour is the enemy of security. As I said in almost every message so far, yes, it should have been documented. Couldn't agree more... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ 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
Quoting David F. Skoll [EMAIL PROTECTED]: Sendmail doesn't allow remote exploit due to recipient addresses with funny characters in them. It certainly hasn't since Milter has been around, so fixing the problem in a milter is dumb. Not if the problem is in the milter, or in the shell between the milter and sendmail via popen(), or not fixable in some other way... But certainly if the milter is rejecting valid email addresses, that should be documented prominately at a minimum. I'd say no excuse for that... Otherwise, your tool becomes irritating or possibly even harmful. Using one tool to fix the deficiencies in another tool is bad security... oh... wait a minute... that's the basis of the entire virus-scanning industry. :-( Finally, a reply to my messages that I can appreciate. :) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ 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
On Thu, Apr 17, 2008 at 09:10:45PM -0400, David F. Skoll wrote: Eric Rostetter wrote: For all I know, from what _little_ I know, the problem is in the popen() call in the milter, Yikes popen() In a piece of SECURITY software??? I'm very glad I've never used Clam's milter. Not directly meant at David, but could you all please stop this crap and open a bug. Continue there please. Thank you. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
