ClamAV blocking good emails

[jigster]

I see that ClamAV is blocking emails that it thinks are phishing emails:

Message from 13.110.227.128 denied - virus of harmful content (Heuristics.Phishing.Email.SpoofedDomain)

But it's blocking a few legitimate emails (e.g. in the above example, that's a legitimate paypal IP address so seems genuine). I'd rather have Rspamd do all the filtering so I want to turn off clamav trying to detect phishing emails. I think turning off PhishingSignatures and PhishingScanURLs in /etc/clamd.d/scan.conf should work (yet untested). Will that file get overwritten on clamav updates? I can't see anything in /usr/local/directadmin/custombuild/configure/clamav/ to use.

 

[Richard G]

that it thinks are phishing emails:

Most likely they are. I checked 13.110.227.128 and that is from salesforce, we are getting a lot of spam from them and as far as I know, these are not related to Paypal.

that's a legitimate paypal IP address so seems genuine

Really? Where did you found that?

I just had real Paypal mails and they are not even near that ip.
Received: from mx0.slc.paypal.com ([173.0.84.225])
Received: from mx2.slc.paypal.com ([173.0.84.227])
All Paypal communication I had until now was from 173.0.84.x ip addresses, so that's why I wonder why you would think the 13.110.227.128 was a Paypal ip and Clamav would be blocking legitimate mail.
Looks to me it's a justified block.

 

[jigster]

Thanks. What made me think the IP was legitimate is it passes an SFP check:

• SPF record for emails.paypal.com has include:cust-spf.exacttarget.com
• SPF record for cust-spf.exacttarget.com has ip4:13.110.224.0/20

Does that not mean paypal.com themselves have set that IP as a legitimate sending source?

 

[Richard G]

What made me think the IP was legitimate is it passes an SFP check:

One should expect that indeed. I did some investigation and at first got a bit confused because I checked paypal.com itself which also has an SPF record and not a strict one. So I thought it might have been spoofed, especially because we had several spam from salesforce recently.

But indeed emails.paypal.com is valid and has a strict SPF record including the ip's you said.

So you were quite correct in your assumption and I was wrong. It is indeed genuine.

Having that said... I don't know if the scan.conf will be updated on a Spamassassin update. It might, but since it's done via the OS nowadays, it might also be a scan.conf.rpmnew will be generated on an update.

You could make the changes, and to be sure it will not be overwritten, you can immute the scan.conf file via the chattr -t option. Unless somebody knows of there is another/better option.

 

[jigster]

I've made the changes to /etc/clamd.d/scan.conf and I'll keep an eye on it to see if the changes get overwritten!

 

[mxroute]

You'll definitely want to keep these tests off. ClamAV doesn't update too often, it might take a while to find out if the config gets overwritten. But yeah, so many legitimate emails come in with HTML like this:

<a href="https://maskeddomain.com">https://realdomain.com</a>

All it requires to hit these rules is that the linked domain be different than the text of the link which has the domain in that text. Using URL shortening services is a good reason for it, but honestly we had it mostly trigger on legitimate bank emails.

 

[johannes]

following this, i just want to add my 2 small question :

x) if /etc/clamd.d/scan.conf will get overwritten, is there maybe a scan.custom.conf option, which not will get overwritten?
x) what is "HTML.Phishing and Email.Phishing NDB signatures" (terms in scan.conf)? What is this "NDB", from where are the signatures coming?