Jason Keltz wrote:
> 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...?
Yes.
>
> 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?
If there is, I don't know of it. The above is pretty much identical to what
I do.
>
> The multiple processing of messages through exim just seems like adding
> extra steps that will only complicate the delivery of mail.
It does complicate delivery, but not much. Once it's setup and running you
don't notice it, other than each message gets 2 entries in the log files.
>
> 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?
I don't know of one. The system filter only gets called once per message,
not once per recipient, so you can't do it that way. The above is the
"simple" way of passing the message through SA before delivery :-). If you
already use procmail then that might be a simpler solution.
>
> 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.
>>
>>
>
>
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@???
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
