On Jul 18, 2016, at 1:03 PM, Reindl Harald <h.rei...@thelounge.net> wrote: >> For that specific case, check that OLE2BlockMacros is set to no. > > the point is this should be independent
Well, it currently isn't. >>> 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 That's why being able to list the exact signatures to ignore rather than having fixed categories in clamd.conf would be a better option. > 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 Yes. >> 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 milter approach is less flexible. With a scoring mechanism, you can rate actual viruses sufficiently negative that the scoring algorithm will always reject them. >>> 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 ClamAV is a virus scanner; it is not its job to perform SPF lookups. Whatever is calling ClamAV to process mail, whether it be a milter interface, amavisd, etc is the software that should be handling SPF checks. >> 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 :-) You have no general obligation to police the entire internet, but one should care about the institutions that you or your userbase interacts with. >> 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 Perhaps English isn't your native language? I spoke precisely; I did not say that epsl1.com was the sending domain. Your logs demonstrate that it, or more precisely mta106b.pmx1.epsl1.com was the MTA sending the message to your mailserver and that mail.paypal.at was the SMTP "Mail from" 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.")...? > > 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 Two points: 1) I got different SPF results here, although hitting a third-party website to lookup the SPF records for mail.paypal.at does give the result you've shown. (I'm travelling and using someone else's network at the moment, so it's possible that they/their ISP is swizzling DNS lookups.) 2) In the absence of MX records stating otherwise, I expect that any mailserver which sends outbound email should be willing to accept inbound mail for the same domains it terminates or relays email on behalf of. >> 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 Well, I've been a mail admin myself since 1990 or so. Someone with an interest in Usenet archeology could probably find on the order of 7000 posts to comp.mail.sendmail by me. ClamAV rejected the message with Heuristics.Phishing.Email.SpoofedDomain; one can run clamscan --debug against the mail (assuming you have a copy kept around in quarantine) to see exactly what is happening. It is extremely likely that the email contained misleading HTML links, presumably intended as a click-through for tracking / marketing campaign purposes. For an example, see: http://lists.clamav.net/pipermail/clamav-users/2015-August/001857.html ...although I'll quote the relevant portion: > LibClamAV debug: Looking up hash > 5E5978396FC0F81B1032CDA256B95D0D65EA0605DBE0643E89231C049A337640 for > urldefense. > proofpoint.com/(26)v2/url?u=http-3A__www.bankofamerica.com_emaildisclaimer&d=AwMFAg&c=ewHkv9vLloTwhsKn5d4bTdoqsmB > fyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U&r=2aYd0Z__pii05laLdA-SVeMDDGgKztEldmYeWZkrEInUKhhOQFnXGHbtYgd15gmS&m=1gyane > 8UIsmcsdK0OgwckCpz8Guf1pgeNHHmOLXQn5Y&s=XYG3vPf_ZUZQe7myUa6pQ8SUpYmn9GNeGK33YzupujA&e=(293) > LibClamAV debug: Phishcheck:URL after cleanup: > https://urldefense.proofpoint.com->http://www.bankofamerica.com Those sort of links are dangerous because phishing attempts try to do exactly the same sort of thing. SPF isn't relevant to ClamAV, since AFAIK ClamAV doesn't perform SPF lookups at all. Regards, -- -Chuck _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
