yes I'm starting to see that. I may need to build a box specifically suited for this using procmail. I had hoped that I could stay with the VPS.
Nevertheless, I've heard two contradictory pieces of advise here and would like to know which is correct or most-near correct. I'm sure there are instances where both pieces of advise work. someone said change the local.cf to a score of 999 which (I think) means that it will override all other spam detection rules. And then another person suggested to remove all the bundled rules. This difference of opinion could be attributed to my lack of clarity, inexperience and what I need. I don't want detection of spam however, when I look at the rules in SpamAssassin (regex expressions, for example) for acting on header information, they are easier to write than procmail or other methods, so I wanted to stick with spamassassin since I have some basic knowledge of regex. If, setting local.cf spam detection to 999 stops the detection of, and acting on, spam, that would work. I would simply write some rules for modifying the subject and deal with the sorting elsewhere. I will try that unless someone sees this as not working. On 01/18/2018 05:34 PM, Noel wrote: > On 1/18/2018 2:09 PM, Chip wrote: >> Newbie excited to use the features of SpamAssassin for a new project >> that needs to flag inbound email for sorting into folders (this can be >> done via cpanel-level filtering) based on keywords in headers (header >> search by SA). >> >> This is a Centos 6.9 machine running cpanel/WHM 11.68.0.23 and >> SpamAssassin version 3.4.1 running on Perl version 5.10.1. >> >> I would like to TURN OFF any and all Spam Identification features and >> only leave behind SpamAssassin's examination of headers and subsequent >> Subject modification based on keywords in headers (such as keywords in >> DKIM or SPF, etc) > Basically all the rules included with SpamAssassin are for spam > identification, and header modification is based on detecting mail > as spam. > > I think SA is poorly suited for your stated purpose of sorting mail > by header keywords. > > If you really really wanted to use SA for this project, you would > need to *remove* all the bundled rules and then add your own header > parsing rules in local.cf, and then SA only knows how to modify the > subject with a spam tag or not at all. > > This seems like more trouble than it's worth for an end product that > doesn't suit your needs very well. There are other established ways > to sort mail with userland imap filters, procmail, seive, etc. > > > Good luck. > > > > > -- Noel Jones >
