[SA-exim] PermReject

Craig Coles CColes at keylabs.com
Thu, 30 May 2002 07:24:49 -0600


Sorry I stepped out last night, thanks for the comments from all...

I like being able to choose between devnull and/or reject levels.  Reject is
a more drastic decision and easier to implement when you are sure that the
threshold you have chosen is acurate.  In my case, I am trying to get users
to let me lower the thresholds a little bit at a time.  My thoughts were to
reject at a higher level, one that I(we) know is doing what it is supposed
to do, and devnull at a lower level just in case you go a little too low and
don't want your clients email rejected (that looks bad!).

Devnull and Reject can co-exist, I don't think it needs to be a 'one or the
other' decision, but that's me.

For Patrice, I was thinking about the system_filter rule solution...  I do
that now for select users but not for all, that's too much mail to store and
keep track of that I would have to be the one to maintain (my mail solution
receives, filters, then forwards mail on to an evil Exchange server for the
company depending on the domain and other attributes).

I'll look into some of the ACL solutions talked about in other mails for
letting mail through un-scanned, thanks.


-Craig


-----Original Message-----
Subject: Re: [SA-exim] PermReject


On Wed, May 29, 2002 at 06:21:30PM -0500, dman wrote:
> | I am currently devnulling above 18 and have been trying to do a
permreject
> | at 20 or above, however I see in the logs that the messages are
'silently
> | tossed' according to the devnull rule of 18.  I can't see where the
> | permreject rule is being referenced.  Have I missed something to enable
it?
> | (yes the SApermreject: 20 line is enabled...)
> 
> That isn't possible as the code is right now.  The relevant section
> begins on line 729 (version 1.3) (snipped for clarity) :
 
Eheh, you're hired :-)

dman is perfectly right.

spamassassin.conf says:
# If you reach this score, the mail is accepted and tossed (/dev/nulled)
# The default value is 99999 which should ensure this never happens.
# You should be real sure that the message is spam because the sender will
# get no notification
#SAdevnull: 20.0

In other words, you can't reject for a higher score than you devnull.
Quite frankly, I don't see why you would want to.
The way I see it, you reject if you reach a certain score, and at least give
the chance for the sender to know his mail wasn't received, but for things
where you're even more sure it's spam, you _could_ just toss it.
I believe  it is  an evil  thing to  do and don't  do it  myself, but  I did
provide the rope :-)

> message.  The code, right now, checks blackholing first, and since all
> messages scoring >= 20 also score >= 18 it is blackholed.  If you want
> to reverse the order of the tests, for your site, you can do that.
  
Correct.
I won't support that in the code, but you can trivially modify it if you
really want to do this.

> Put those user's local parts in /etc/exim/sa_skip (lsearch format).
> In the SAEximRunCond setting include something like this :
> 
> SAEximRunCond: ${lookup {$local_part} lsearch {/etc/exim/sa_skip} {0}{1}}
 
Yep, although you'll probably want this:
SAEximRunCond: ${if and {{def:sender_host_address} {!eq
{$sender_host_address}{1
27.0.0.1}} {! def:h_X-Spam-Flag:} } {1}{0} {${lookup {$local_part} lsearch
{/etc/exim/sa_skip} {0}{1}}}}

This will save you from:
1) scanning messages that are generated locally on your machine
2) Not scan messages that were already scanned elsewhere (unless you decide
   not to trust the header)

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet
cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP
key