Very well stated. Bravo! The end point here is to examine the email headers that specifically refer to dkim and spf signatures. Based on fail or pass, or some combination in concert with the sender's email address, they get moved into fail or pass folders.
That's it! I know there are other methods for doing this - procmail, mimedefang, sieve, etc. etc. etc., but I'm somewhat limited in using those because although they might be intrinsically better for this, they do not play well with the cpane/WHM VPS I use and to which I am married because there are other features of the cpanel/WHM which come into play with this project, that are attractive and not available in a home-grown smtp server box. So using what I have rather than jumping ship and starting from scratch is preferable. I have played a bit with the local.cf and see that I can move into folders depending in the outcome of the examination of the headers. But that is with spamassassin still identifying spam, which is unnecessary in this case as this project will never attract spam - I know that is hard to believe in, but it won't. So the method of using Spam Assassins built in regex procedures for examining emails is attractive. On 01/18/2018 06:24 PM, Alex Woick wrote: > Chip schrieb am 18.01.2018 um 23:43: >> 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. > I think it isn't clear what your final goal is. What is the goal you > want to achieve, how should the result look like? > > SpamAssassin is something that is inserted into the flow of mail, > usually on a mailserver, and does nothing else than read each mail > that is piped through it and add some headers to each mail. That's it. > It adds headers that tell how that mail was classified by > SpamAssassin: spam or not spam. > > Then, some process that comes after SpamAssassin is able to read these > headers and perform some action upon the mail: for example, it could > move mails to a "junk" folder that were classified as spam and can > leave other mail alone. If you don't implement such process, no action > will be done. > > How SpamAssassin does the classification is determined by the rules > that come with it. It will do analysis of headers, analysis of text > and may consult remote services like spamcop. > > Each rule returns a score. A positive score means the rule says this > is an indication for spam, and a negative score means the rule says > this is an indication for non-spam (ham). All scores are added, and if > the value is above 5, SpamAssassin classifies this mail as spam. If it > is below 5, it classifies the mail not as spam. If you raise this > threshold to 999, SpamAssassin will simply declare no mail as spam any > more, because there are probably never enough matching spam rules that > add up above 999. So doing this is somewhat pointless, and so I get > back to my initial question: what is the result for your users that > you want to produce after your project is finished? > > If you want SpamAssassin classify and mark mail but take no action, > simply fold SpamAssassin into your mail server and let it do the > classification. Each mail will get the SpamAssassin headers but will > be delivered as before. But you can examine the classification by > examining the headers of the mails in your mail reader. If you and > your users find the classification is fine, you can do the next step > and implement actions on the classification. >
