Am 18.07.2016 um 18:14 schrieb Charles Swiger:
On Jul 16, 2016, at 7:40 AM, Reindl Harald <h.rei...@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 heuristicsThis 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-hp2v200000155ca866916a7a126f4bbe5c7c0...@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 <sp...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
