Jim Roberts wrote:
| I understand the objective is to reject spam at SMTP time, except for
| specific recipient(s). Is it possible to use the "fake reject" option, to
| effectively reject the mail at SMTP time, but keep a copy? Add a "magic
| header" to indicate this special circumstance. Then put something in the
| system filter to catch this case, delivering it only to "spamlovers," and
| /dev/null for any other recipients. Would this work? Just a thought.
The flaw in this plan (fakereject after DATA) is that the sender gets a
failure report stating delivery has failed to *all* recipients, including
the spamlover. You may or may not consider this a problem ;-)
As has already been suggested, the answer is to force split
batches with selective use of defer. It looks like this:
MAIL FROM: <foo>
250 OK
RCPT TO: <user1>
250 OK
RCPT TO: <user2>
250 OK
RCPT TO: <user3>
4XX users have differing spam profiles - please try again in a later batch
We've done this happily for a year with 30,000+ users, with a couple of
hundred spam-lovers. Alan has posted a recipe.
And earlier Tim Jackson wrote:
| It probably isn't a huge problem though. Spam these days seems to be
| mostly single-recipient (per SMTP session, anyway), so it's likely that
| the problem circumstance will arise relatively infrequently
That's what we expected initially. So we first implemented a simpler
scheme where if any recipient was a spam-lover then everyone gets the
mail. But the volume of multi-recipient spam was sufficient that we got
frequent complaints from spam-lovers - where the spammer had included a
spam-hater as a "joker".
Perhaps this stems from the vaguaries of our University. I remember one
case where a lover shared an office with a hater and they both (for some
reason) seemed to be included in a several-times-per-day spam mailing...
The split batches scheme solved this completely.
Incidently, as we have 2 profiles and 2 MXs, the majority of legit senders
that get a defer appear to retry on the other MX within seconds. It's
rare for senders to delay till the next queue run e.g 15 mins. This
should generalise to more profiles and more MXs.
