Virus Checks before Spam

[XN-Matt]

Could Proxmox give some rationale behind placing the Virus checks after Spam?

If a message is being caught as a virus, it really doesn't matter what the spam checks have scored.

This eats up valuable DNSBL queries for messages that will always be caught regardless of the score.

It would be useful if the order could be changed to scan for viruses first and if it then passes, to spam score it. Or at least give us the option of scanning order.

(Context, we add more checks in to our clamav setup to catch common phishing messages too and we see 10+% being blocked for this alone that doesn't need further spam checks)

 

[Stoiko Ivanov]

Could Proxmox give some rationale behind placing the Virus checks after Spam?

The mail is virus scanned first, before being sent to SpamAssassin for processing.
However a few things happen before the mail is queued in the first-place - the checks done by the mail-proxy - which include the dnsbl-checks done by postscreen - the rationale for doing those early is quite well laid out in the postscreen Readme: https://www.postfix.org/POSTSCREEN_README.html
do you mean those?

 

[XN-Matt]

I don't.

The mail is being scored for Spam under SA. Our message headers have `X-Spam-Score: XX` added. This ads to those messages which are spam but also adds to those picked up as Viruses.

It would indicate the message is going through SA then Virus checks or Virus, being caught but still sent via SA.

If a message is a virus, why would it need to be SA scored as the outcome will be no different (i.e held as a virus).

 

[XN-Matt]

Any further comment here on the last post as to the processing logic and wasting of valuable DNSBL queries on "virus" messages which will be caught either way.

 

[Stoiko Ivanov]

The workings of PMG are as described in my previous posts - and they have proven to work quite reliably.
The initial requests to the configured DNSBLs in the mail proxy help in dropping junk mail early (see the postscreen readme).
The scanning for viruses happens unconditionally (but what happens with such mails is completely dependent on the configured rules)
Finally the from/when/what (what handles spamanalysis) objects are processed before the to objects, and just after the actions are carried out

So with the current design (which we currently do not plan to change) it is not possible to short-circuit processing

I hope this explains it