Hi there, On Fri, 24 Aug 2012, Mark Foster wrote:
First time poster, please indulge me as I get to grips with how this group works....
Read all the docs that you can find, especially http://www.clamav.net/doc/latest/clamdoc.pdf and http://www.clamav.net/doc/latest/signatures.pdf although you could be forgiven for not finding the latter. :)
... I submitted this as a false positive several days ago but it appears to still trigger, so i've been forced to have a bypass for Clam worked in for this customer (less than ideal). Interested in others exposure to circumstances like this, wonder if i'm alone in seeing this behavior (or similar) and what the best method of moving forward is?
You haven't told us what mail software you're using so it's difficult to give specific advice but systems with sufficient flexibility exist. If you use the .ign2 method as described in the signatures document it means that all your customers' mail will be treated in the same way, which might not be quite what you/they want. One approach could be to have clamav-milter flag all 'suspicious' mail such as this by adding a header, but not reject the mail outright, and then have something like milter-regex filter out the suspicious encrypted mail unless addressed to particular customers who want to receive it. This assumes that you are using milters, but there are other ways of achieving the objective. Of course if my customers insisted on accepting encrypted mail, I should ask them to confirm in writing that they understand that such mail can't be scanned effectively for threats. -- 73, Ged. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
