Sty 17 13:00:47.233 dbg: util: PATH included '/usr/local/bin', keeping Sty 17 13:00:47.233 dbg: util: PATH included '/usr/local/sbin', keeping Sty 17 13:00:47.233 dbg: util: taint mode: deleting unsafe environment variables, resetting PATH Sty 17 13:00:47.233 dbg: util: running in taint mode? yes Sty 17 13:00:47.226 dbg: generic: Perl 5.020002, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin Sty 17 13:00:47.225 dbg: logger: logging level is DBG Sty 17 13:00:47.225 dbg: logger: adding facilities: all # and a well-trained bayes DB can save running rules, tooĮndif # Mail::SpamAssassin::Plugin::Shortcircuit # if you have taken the time to correctly specify your 'trusted_networks', # the opposite blacklisted mails can also save CPU # shortcircuiting plugin is active, causing early exit to save CPU load. # default: strongly-whitelisted mails are *really* whitelisted now, if the Ifplugin Mail::SpamAssassin::Plugin::Shortcircuit # Some shortcircuiting, if the plugin is enabled # them to UTF-8 before the text is given over to rules processing. # Whether to decode non- UTF-8 and non-ASCII textual parts and recode # Set headers which may provide inappropriate cues to the Bayesian

# Bayesian classifier auto-learning (default: 1) # Set the threshold at which a message is considered spam (default: 5.0) # Set file-locking method (flock is not safe over NFS, but is faster) # Set which networks or hosts are considered 'trusted' by your mail # modifying the original message (0: off, 2: use text/plain instead) # Save spam messages as a message/rfc822 MIME attachment instead of # Add *****SPAM***** to the Subject header of spam e-mails

# Only a small subset of options are listed below # See 'perldoc Mail::SpamAssassin::Conf' for details of what can be # This is the right place to customize your installation of SpamAssassin. => /etc/mail/spamassassin/v320.pre /etc/mail/spamassassin/v330.pre /etc/mail/spamassassin/v340.pre /etc/mail/spamassassin/v341.pre local.cf <= Loadplugin Mail::SpamAssassin::Plugin::DKIM # renders the DomainKeys plugin redundant. For some reason, the 'header' rule only seems to trigger the filter if the conditions in the 'body' rule are also met - but not vice-versa, the 'body' rule triggers even if the conditions in the 'header' rule aren't met.=> /etc/mail/spamassassin/customrules.pre /etc/mail/spamassassin/init.pre /etc/mail/spamassassin/local.cf /etc/mail/spamassassin/sa-update-keys /etc/mail/spamassassin/v310.pre /etc/mail/spamassassin/v312.pre version 0.20 or later is installed, this When I sent test messages to accounts on that server from GMail & Hotmail accounts that included words in the 'body' rule, the filter was triggered - and when I sent messages from the same GMail and Hotmail accounts without any of the words in the 'body' rule, they didn't trigger the filter.īut when I send a test message from a non-GMail/Hotmail account, containing one of the words from the 'body' rule, that also triggers the filter.

Obviously the goal is to catch messages that match BOTH the 'header' and 'body' rules - and at first it appeared to be working. Header GMAIL_HOTMAIL_SEO_SPAM From =~ GMAIL_HOTMAIL_SEO_SPAM /seo|india/iĭescribe GMAIL_HOTMAIL_SEO_SPAM Web dev and SEO spam from GMail & Hotmail I've added the following to my /etc/mail/spamassassin/local.cf file: # GMAIL & HOTMAIL SEO SPAM I've trained SA against thousands of examples of those spam messages, but SA usually scores below the spam threshold because they pass all of the other tests (SPF, RBL checks, etc), even if the bayesian filter catches them. I'm attempting to setup a custom SpamAssassin filter to deal with the huge amount of SEO & web dev spam we get from GMail & Hotmail accounts - ideally, server-wide, since there are multiple mail hosted on that server.

Spamassassin rule