Hi Nigel,
Thanks for your response.
The system-wide spam processing, as you said, won't take into accounts
users own whitelists/blacklists/bayesian filtering/etc. Since most of
our users have been run spamassassin in their own personal accounts, and
doing these things, I don't think I could take the priviledge away. By
scanning the spam a second time on the server, it simplifies the user
setup, which I like to do.
The problem is that, to me, using the transport/router method seems just
like a bit of kludge -- I think this is what you're referring to...?
spamcheck:
driver = pipe
command = /usr/local/bin/exim4 -oMr spam-scanned -bS
use_bsmtp = true
transport_filter = /usr/bin/spamc
home_directory = "/tmp"
current_directory = "/tmp"
# must use a privileged user to set $received_protocol on the way
back in!
user = exim
group = exim
log_output = true
return_fail_output = true
return_path_add = false
message_prefix =
message_suffix =
# SpamAssassin
spamcheck_router:
no_verify
check_local_user
# When to scan a message :
# - it isn't already flagged as spam
# - it isn't already scanned
condition = "${if and { {!def:h_X-Spam-Flag:} {!eq
{$received_protocol}{spam-scanned}}} {1}{0}}"
driver = accept
transport = spamcheck
----
Is there any other simpler way to do this other than the above?
The multiple processing of messages through exim just seems like adding
extra steps that will only complicate the delivery of mail.
This just seems like such a simple problem, yet with a complicated
solution... I can either add the above, or let users add one single line
to their .procmailrc file that calls spamc... I wish there was some
middle ground.. is there not some "simple" way I can just pass the
message through the spamc filter before delivery on the mail server?
through say, an exim system filter or something like that?
Thanks..
Jas.
> Jason Keltz wrote:
>
>> I'm working on setting up my exim 4.50 system to do content scanning
>> with SpamAssassin through the data acl. I want to be able to do two
>> things:
>>
>> 1) reject messages at a system threshold
>> 2) add spam headers to the message, but using the recipients
>> spamassassin prefs (even if there are multiple recipients)
>>
>> The first part is easy:
>>
>> deny message = This message scored $spam_score spam points.
>> spam = nobody:true
>> condition = ${if >{$spam_score_int}{120}{1}{0}}
>>
>> The second part is my problem. I basically understand the issue of
>> multiple recipients. I know that if I am considering user settings,
>> and a message comes in where two users have conflicting spam score
>> settings, I cannot both ACCEPT and REJECT a message at the data
>> level. I understand that some people get around this by enforcing
>> single recipients, etc. but this solution is not acceptable for my
>> environment. What I would like to know is whether I can still ACCEPT
>> a message that is at least less than the system threshhold, but at the
>> same time, add "Spam: Yes" or "Spam: No" headers to the message for
>> each recipient, depending on their own personal configuration of
>> spamassassin in their home directory. I'm just not sure if exim
>> allows for this syntax in the ACL condition, or whether a single
>> message cannot have different headings for different users...
>>
>> If this is not possible, I still wonder how I might enable Exim to
>> "rescan" each message with "spamc" for each user so that I could at
>> least add Spam headers to messages that are not rejected. Users could
>> then choose what to do with messages that are less than the system
>> threshold -- do nothing, move them out of their inbox with procmail, etc.
>>
>> Thanks for any help you can provide..
>>
>> Jason Keltz
>> jas at cs.yorku.ca
>>
>
> Yes, you can do what you want, but not in the ACL.
>
> If a message passes the system wide acceptance test, then you accept it.
> You can use a pipe transport to process the message again, per
> recipient, using the recipients own preferences. If the recipient's
> preferences are only on threshold you may be able to avoid re-processing
> the message through SA, but if they have different rules, or
> white/blacklists then you have to use SA to process the message again.
> If the message fails now above some threshold you can no longer reject
> it, it's already been accepted. Finally the pipe transport passes the
> message back to exim to handle delivery.
>
> It's quite a significant overhead if you need to re-process the message
> with SA, so be sure that you really want/need to do this and have
> sufficient memory and processor capability to handle the load.
>
>
