Re: [exim] SPAM Filtering - Losing the war!

Vitaly A Zakharov wrote:

*snip* (details of some well-written examples...)

We would add that it can be very beneficial to defer actually 'acting on' these
strict tests (rDNS fail, HELO mismatch, RBL hit, etc.) until at least
acl_smtp_rcpt phase, where 'per-recipient' filtering is practical.

The reasons are economic.

Given that in any given 'organization-specific' domain - and arrivals are
grouped by target domain - there is, or most often *should be* - at least one
address that is *very* forgiving, and many others that are less so.

Example: Clients to whom a missed opportunity for a unit sale to a new customer
is worth several thousand US$ per each. New user registrations. Helpdesks.

So - a 'sales@<domain>.<tld>', 'info@<domain>.<tld> or similar spam-target
initial-point-of-contact address needs the Mark 1 human eyeball to sort copious
arrivals of spam in order to find the one or two potentially valuable arrivals -
then respond and whitelist them if need be.

Best if staff can share that sort of unpleasant workload!

In acl_smtp_rcpt, we can pull the per-recipient thresholds, still reject any/all
that are NOT 'tolerant' recipients, and onpass only the survivors.

Also - the 'tighter' the filters, the more attention needs to be paid to
maintaining very current exception whitelists and applying code that has a
similar 'automagical' effect. e.g. - allowing traffic from any domain your
clients have intentionally *sent to* [ ever | x-times in y-months), and similar
lookups.

We are, after all, not supposed to shoot the bystanders in this 'war'.

;-)

Bill