[clamav-users] ign2 whitelist don't work

[Charles Swiger]

On Jul 16, 2016, at 7:40 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> You must disable Heuristics using clamd.conf and clamscan options.
> 
> that's not a useful answer since the only option is "HeuristicScanPrecedence" which don't disable anything and so "you must do this" without saying how is pointless
> 
> "PhishingScanURLs no" would also disable "safebrowsing.cvd" and likely also most of the 3rd party rules
> 
> disable heuristics entirely (given there would be an an option) would also disable "Heuristics.OLE2.ContainsMacros"

For that specific case, check that OLE2BlockMacros is set to no.

> it makes no sense that you can't disable specific heuristics

This is a reasonable point.  One should be able to use the ign2 whitelist to disable specific heuristics, as well as having more fine-grained control within clamd.conf.

In the meantime, however, if you want to have PhishingScanURLs or PUA categories enabled, then you should use any matches returned under Heuristics.* or Phishing.Heuristics.* as a soft fail and use it for scoring purposes rather than as a hard fail.

> _______________________________________________________
> 
> such false positives are *unacceptable* in case of the monthly account overview and frankly i have not seen any hit which was not very likely a false positive (as example newsletters from payment companies over services like mailchimp)
[ ... ]
> Jul  8 14:42:10 mail-gw postfix/cleanup[19493]: 3rmDds0LjczB44: milter-reject: END-OF-MESSAGE from mta106b.pmx1.epsl1.com[142.54.244.106]: 5.7.1 Virus found or dangerous attachment: "Heuristics.Phishing.Email.SpoofedDomain"; from=<bounce-HP2v200000155ca866916a7a126f4bbe5c7c0237 at mail.paypal.at> to=<*****> proto=ESMTP helo=<mta106b.pmx1.epsl1.com>

While I'd agree that it should be unacceptable for financial institutions to use third parties for email distribution of sensitive content, I suspect that wasn't your intended point.

I also believe that it should not be acceptable for financial institutions-- or anyone who values their reputation-- to send emails containing HTML links where the domain of the link text shown to the user does not match the domain of the actual A href attribute.

Have you contacted PalPal and asked them to investigate why they are sending emails which look like phishing attempts via epsl1.com domain, which domain not only doesn't appear in the SPF records for paypal.com / paypal.at, but also doesn't appear to have any published MX records at all (per "dig -t mx epsl1.com.")...?

I did.  And I have since stopped using PayPal entirely after they failed to improve their practices.  The more people who contact them via <spoof at paypal.com> both for phishing attempts and for supposedly genuine mail from PayPal which triggers AV phishing warnings, the better.

Regards,
-- 
-Chuck