[Exim] selective defer when some users don't want spam filte…

Top Page
Delete this message
Reply to this message
Author: Alan J. Flavell
Date:  
To: Exim users list
Subject: [Exim] selective defer when some users don't want spam filtered
OK, I've implemented our first cut at selective defer when the
addressee list consists of a mixture of those who want to be excused
spam filtering (including "postmaster" and "abuse") and the rest of
us. (This was motivated by a posting of a similar idea in this list's
archives, but which I'm sorry to say I can't locate again now. But I
acknowledge and credit the earlier posting anyway ;-)

It's been in effect for a week now; I hadn't realised just how
relatively rare these occurrences are (it's surprising how intrusive
just a few of them were perceived to be, i.e spammers adding
postmaster to their addressee list could be assured of promptly
earming a place in the blocking lists, but meantime it had been acting
as a joker to get their spam through to all the other recipients).

Anyhow, to tell the truth, it seems that we're only getting 2 or 3
such events per day on average.

At the moment it's all done at the very start of the RCPT ACL, so it's
done even before the recipient addresses have been tested for
validity - not sure if that matters, though.

So the logic is this. Each RCPT TO is tested to see whether it's one
of the shortlisted users who asked for their mail not to be
spam-filtered - plus "postmaster" and "abuse" who get the same
treatment. For brevity I call these recipients "suckers". Anyone not
in that class, we rate as "normal".

(I'm not showing the actual ACL statements because I think they're
presently sub-optimal, but the logic that they implement seems OK).

We don't apply this treatment to mail from our own users (i.e if the
mail is being sent by one of our own IPs, or the sender has
authenticated).

The test is done right at the start before going into any checks of
blacklists, RBL, callback etc., so it affects all (outside) senders
who present a "mixed" addressee list, whether spammer or bona fide.

If it's the first RCPT TO ($acl_m5 is undefined), then we note the
type of user (1 = normal, 2 = "sucker") in $acl_m5 and proceed as
usual (i.e spam filtering for normal users, no spam filtering for
"suckers").

If it's not the first RCPT TO, we compare the type of user (normal or
"sucker") with the value that was saved in $acl_m5, and if they're
different, we "defer" with "please try this recipient again later".
Otherwise, of course, we proceed as usual.

Thus, if the first recipient was a "sucker", we defer all the normals,
and vice versa.

So far, this appears to be working as designed. Some senders respond
by retrying with us shortly afterwards, whereas others respond by
immediately palming the retries off on our secondary MX. The latter
makes spam rejection slightly less effective, but it's clearly still a
lot better than the previous situation had been.

In theory, a spammer who was not bothering to retry would fail to
reach our "suckers" if their first addressee was a "normal", but I can
live with that ;-) Can't say I've spotted any examples of that, but -
as I say - we've collected less than two dozen instances during the
week that this has been in effect.

So I thought it was time to put this on record and see if anyone had
any comments on the procedure, at least on its principles of
operation.

cheers