|
|
>>>>>
>>>>> I have a system-wide rule which delivers all recognized spam addressed to all domains and recipients to one centralized spam folder (of an account created exclusively for this purpose) for temporary storage and teaching SpamAssassin’s bayes filter.
>>>>>
>>>>> I’m considering changing my strategy to having a per-user spam folder instead. I’m thinking this could, at the very least, empower the users to actually receive these messages and manage possible false positives.
>>>>>
>>>>> Does anyone have any experience or insights about the strengths and weaknesses of alternate handling strategies?
>>>>>
>>>>> What would be the best way to implement this? Do I just need to make a ’Store In’ domain-wide rule for each domain instead of the single system-wide rule I have now?
>>>>>
>>>>
>>>> You can use this option in cgpsa.conf (line 552 in my file), and keep using the server wide rule.
>>>
>>> Ahh…I had forgotten about that. Thanks for the reminder! :)
>>>
>>> So, here’s my current server-wide processing rule. Do I just need to delete the ’Store In’ action and tweak the cgpsa.conf dma settings?
>>>
>>> Subject is *SPAM-PALVELIN*
>>> Header Field is X-Spam-Flag: YES*
>>>
>>> Add Header
>>> X-Spam-Global: YES
>>> Write To Log
>>> Spam (GLOBAL) Detected
>>> Store In
>>> ~spam/Junk-SpamAssassin
>>> Discard
>>
>> After setting dma in cgpsa.conf (and restarting extfilter), you can disable that rule completely. Just keep the one above, with the "ExternalFilter = cgpsa" action.
>
> ”…the one above”?
>
In a setup like your's, we typically have a minimum of two Server Wide Rules ("the one above" is the high priority one, the one that actually fires CGPSA).
- Priority 9: run "cgpsa"
- source not in authenticated
- any Route is LOCAL*
Action = ExternalFilter CGPSA
- Priority 8: Ditch High scoring SPAMS
- Header Field in X-Spam-Level: +++++++++*
Action = Discard
- Priority 7: Put lower scoring SPAMS somewhere for review/sa_learn, whatever
- Header Field in *X-Spam-Level: ++++*
Action = Store In ~/spam/folder
Action = Discard
Now,
In a DMA enabled solution, I typically just use the first rule.
CGPSA takes care of dropping any message tagged as spam into the user's Junk folder.
You don't need rules to evaluate any headers added by SA or by the highest priority rule.
BTW,
These are the headers my SA puts in
SPAM
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.bulckens.com
X-Spam-Level: +++++++++
X-Spam-Status: Yes, score=9.5 required=4.8 autolearn=no
HAM
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.bulckens.com
X-Spam-Status: No, score=-1.6 required=4.8 autolearn=no
BTW2
/etc/mail/spamassassin/local.cf, on how I like my SA headers
# _______________ First we clear all headers
clear_headers
# _______________ Put headers back in the way we like them
add_header spam Level _STARS(+)_
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ autolearn=_AUTOLEARN_
# _______________ add complete report - debug only
# add_header all Report _REPORT_
# _______________ rewrite subject
rewrite_header Subject SPAM --
# _______________ Save spam messages as a message/rfc822 MIME attachment instead of
# _______________ modifying the original message (0: off, 2: use text/plain instead)
report_safe 0
------------------------------------------------------------------------
zwartopwit.be - Drukkerij Bulckens
http://www.zwartopwit.be
Beestig drukwerk van A tot XXL
Industriezone Herentals
Grensstraat 9, 2270 Herenthout
+32 (0) 14 28 58 78
------------------------------------------------------------------------
|
|