Comments inline: Dirk Nienhaus said: > [EMAIL PROTECTED] wrote: >> Since some of the emails from this list had already been processed by >> somebody else's spamassassin (the sender's perhaps?) and had the >> X-Spam-Status header, my procmail rule bypassed the spamassassin filter. > > Hi, at first thank you for the fast answer! > if i understand you right, you think that a sa processed email become a > required status=9999.0? >
My thought is that your upstream provider _may_ be running emails through spamassassin before they even get to you. If so, they may have their threshold set to 9999 so that the tests are all run, but it is up to the end user to decide if it is spam or not. Perhaps they expect you to edit your user_prefs on a shell account somewhere? This is all speculation, so purchase a salt lick of your choice. It would help to know how your email is delivered. For instance, I personally have some mailboxes that I check using fetchmail. These mailboxes are subject to "upstream provider" checks, possibly another installation of SpamAssassin. I also have domains with MX records pointing directly to my mail server. Mailboxes in these domains are not subject to upstream manipulation. >> I don't remember where I got the idea to skip spamassassin if the >> X-Spam-Status header was set, but I believe I found it somebody's >> reference page long ago. If that's the case, some spammers may have >> picked up on this as well and added their own X-Spam-Status header, or >> perhaps you are seeing some processing happening upstream... Based on >> the >> high score of your example (6.3), the latter seems more likely. > > Yes! A faked header is thinkable :( Possible, yes. However, if I were a spammer and I were trying to fake a SpamAssassin header in order to make the email look like ham, I would have faked a much lower score. It's worthwile to note what happens when you send an email that has SpamAssassin markup through SpamAssassin a second time: SpamAssassin will rewrite the X-Spam-Status, X-Spam-Flag, etc. headers (in my 2.55 setup, at least). Thus, if you are sending every email through SpamAssassin, which I believe is a typical scenario, then SpamAssassin is probably rewriting the headers anyway including the X-Spam-Status and required hits. In that case, my guess is simply wrong and I recommend you forget this line of reasoning and look for other causes elsewhere. >> In any case, I've changed my setup to skip filtering only if my custom >> header exists (which indicates my local spamassassin has processed the >> email), as follows: > > What? You create your own sa-header? Or which information in the header > did you take? I have no 100% save idea ;) In my procmailrc file, I simply check for the existance of my own personal header in all emails before processing them with SpamAssassin. If the header already exists in the email, I skip SpamAssassin. If the header does not exist, I add the header, then process the email with SpamAssassin. In other words, the custom header that I add is an indicator that this email has been checked by _my_ copy of SpamAssassin with _my_ configuration. The header name I use is "X-CUSTOMTHINGGY-SA". The only important thing is that it's my own _personal_ header name, however. I've seen at least one other mention on this list of required hits changing. Do more reasearch, keep watching, and of course report to the list in the end if you find out what is causing your problem. -chris ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk