Re: [Exim] spamassassin only for specific domains: how?

Hi Tom, on Mon, 26 Apr 2004 20:16:52 +0200 you wrote:

[per-domain customisation of spam scanning]

> i'll probably go for option three, i.e. taking the spamcheck out of
> DATA time and put it in a router/transport combination. i'd still like
> to get rid of the spam though, without sending bounces to unsuspecting,
> forged senders.
>
> however, even after scouring the exim 4.30 specification i can't get my
> head around how to achieve that.

That's because you can't, without dumping the (suspected) spam to
/dev/null. This isn't a limitation of Exim, it's a limitation of SMTP. You
only get one chance to reject at SMTP DATA time, but there might be
multiple domain recipients. If you accept and start passing through
routers to SA, then - as you have discovered - you're a bit stuck. You
have spam in hand but nothing to do with it except create collateral spam
(please don't) or devnull it (makes your mail system unreliable).

However, particularly if this is only for an odd client, you may well find
that some of the other methods mentioned in the various documentation will
work really well - for example Alan Flavell's "spam profiles"
configuration method. Basically, whichever the first recipient is in an
SMTP transaction sets the "scan profile" for that SMTP session. So if the
first recipient is a "don't filter my mail please" recipient, then the
session is a non-scan session, and you SMTP tempreject any recipients that
*do* want their mail scan. The opposite naturally applies too.

Obviously, it will lead to delays in mail delivery in the case of an SMTP
session with a mixture of recipients with different scan preferences. This
might be offputting, but consider the following mitigating factors:

- depending on your circumstances, it's quite possible that messages with
multiple recipients across unconnected client domains is relatively rare.

- if it's only an odd client that wants it, this may well make the
incidence of messages with mixed scan profiles even smaller

- with a yes/no scan profile (i.e. 2 options), then any given message will
take a maximum of 2 mail sessions to be delivered. Therefore the *maximum*
delay will be 1 retry by the sender, which is typically a relatively small
amount of time (though of course this is outside your control).


So some kind of "scanning profile" system, implemented at SMTP time, may
well be worth looking into. It's surprisingly easy to set up. Check the
list archives for references.


Tim