Re: [Exim] .forward files and spam counterfeits

--On Thursday, November 27, 2003 18:55:15 +0000 "Alan J. Flavell" <a.flavell@???> wrote:

> On Thu, 27 Nov 2003, Pat Lashley wrote:
>
>> My first thought would be to ensure that there's something unique to
>> your site in the 5xx rejection response; then set up an ACL for null-
>> sender messages, with a condition that does a match on $message_body
>> looking for your rejection notice.

> ...
> Suppose, for example, that one of our users was the owner of a mailing
> list at a remote mailing list server. Indeed, we happen to know a
> couple of them who are, and there could well be others.
>
> Now consider the scenario where some other address at our site is
> involved in an incident where we reject a mail from the list: the
> rejection would then be notified, and rightly so, to the mailing list
> owner. Isn't there a risk that we'll recognise our own rejection
> notice tag in there, and refuse the rejection? That would clearly be
> wrong, but I don't know how to reliably distinguish the various
> situations that can arise.

Hmmm. Yes, that would happen with primitive mailing lists (such as
a simple alias expansion.) But modern mailing list management software
doesn't send every bounce to the owner. It keeps track of failures
and automatically suspends delivery to addresses which have remained
undeliverable for an extended time. Then, if configured to do so,
it notifies the list owner that some members have been suspended.

To add safety, you could make the condition attempt to recognize the
start of an included message and only search for your 5xx string in
the part above that (and below the current headers.) At that point
the condition is getting complicated enough that you might want to
use a perl function.


Alternatively, list managers could ask to be put on a white list
of recipients for which the unique rejection string recognition
would be bypassed.



> This is why I was sort-of hoping someone else had actually solved this
> kind of problem in practice already and would be willing to pass on
> their advice and any got'chas.

Yep, a known working example always provides a nice warm fuzzy
feeling... I hope someone steps forward with one. I've been
lucky enough that this particular problem hasn't cropped up at
any of the sites I administer.



Ok, here's another idea. Let your users register their forwards
with you; so that you have a database of their foreign address
and the local address to which it is forwarded. Set up a drop
ACL that matches when the sender is a registered foreign address
and the recipient is the matching local address and the spam score
is over the threshold. (Drop is safe because you know that any
bounce would just loop back to the current recipient.)

Of course, you have no way of verifying that the registered foreign
address is actually forwarding to the local address; but it doesn't
really matter since the person controlling that binding is the owner
of the local address. (Effectively, they are saying "Any spam to
me from that address should be dropped instead of bounced." This
is basicly equivalent to setting up a personal white list with that
address; and then letting their MUA's filters discard the message.)

And this solution only works for single-recipient messages; but
the forwards you're talking about should almost always fit that
category by the time they get to you anyway. (There is still the
possibility that the spam originated on, was relayed through, or
sent to a mailing list on the site doing the forwarding; in which
case it might be aggregated with other copies aimed at other users
at your site.)


A nearly equivalent solution would be to set the db up as personal
whitelists where whitelisted from addresses have a much higher spam
score rejection threshold. Then deliver-time filtering can be used
to check the score and discard the message or deliver it to a different
submailbox. (Again, very easy to do with Cyrus/sieve. Should also
be easy with procmail or similar filtering.)



-Pat