[clamav-users] ign2 whitelist don't work

[Reindl Harald]

Am 18.07.2016 um 18:14 schrieb 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.

the point is this should be independent

>> 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.

fine-grained control would be difficult given you have a mix of 3rd 
party signatures to know which affects what

i am really shocked that ign2 whitelists don't work in a simple way that 
whatever is triggered due the scan is compared agianst the whitelist and 
just skipped as it was never there

> 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.

running as milter that's not possible and when you run clamd only as 
spamassassin plugin any whitelisting would skip the complete virus scan 
what is the reason to have the milter as second instance with different 
signatures

the current beahvior is completly unflexible even with having both clamd 
as spamassasin-plugin and one as "last resort" milter

>> _______________________________________________________
>>
>> 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.

they use SPF and until clamav can't do a SPF test it must not run 
phising tests unconditionally while the real problem is that 
"PhishingScanURLs no" also disabled google safe browing signatures

> 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.

frankly i am sorry that i can't play police for every institution out 
there and explain them how to handle email :-)

> Have you contacted PalPal and asked them to investigate why they are sending emails which look like phishing attempts via epsl1.com domain

since i am mailadmin and don't have access to my users email no
however - "epsl1.com" is *not* the sending domain
you confuse hostnames and sender address

> 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.")...?

sorry but you don't understand SPF really good and since when have MX 
records something to do with outbound mail

mail.paypal.at.         3600    IN      TXT     "v=spf1 
ip4:142.54.244.96/27 ip4:142.54.244.128/29 -all"

142.54.244.106 is the sending IP

> 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.

again: i am a mailadmin and can't babysit every communication between 
customers and their communication channels, i can only look at the SPF 
which was correct and so say it is a false-positive and in that case the 
fault of clamav

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clamav.net/pipermail/clamav-users/attachments/20160718/80d6f0f1/attachment.sig>