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 
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 

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



## List details at 
## Exim details at
## Please use the Wiki with this list -

Reply via email to