If rules are only supposed to apply to a specific user, you can specify this in ~/.spamassassin/user_prefs. The rules you set here are used independently of the executing user. The right place for site-wide application of rules is therefore /etc/mail/spamassassin/local.cf.
#Spamassassin rule upgrade
The reason is simple: When you upgrade the filter, all existing rules are overwritten in this folder – including your changes. It is not usually imperative to become acquainted with this area, but if, for example, you are faced with an above average number of false positives, it might be useful to create your own custom rules.īefore you get down to writing your own rules, you should be aware that it is explicitly discouraged to add rules to the *.cf configuration files in the /usr/share/spamassassin directory. SpamAssassin already has a solid basic configuration of rules, but they only cover the best known advertising email. Note that this test slows the environment – possibly even a lot. If you find relatively high values here, the rule affecting performance is identified. In the logfile timing.log you will find out how long it took to process the rules. Add the following line in the file ~/.spamassassin/user_prefs: loadplugin !HitFreqsRuleTiming !HitFreqsRuleTiming.pm
#Spamassassin rule download
Download the SpamAssassin rule timing plugin HitFreqsRuleTiming and copy it to ~/.spamassassin. If you think your rules might be acting as a bottleneck, you can easily find out. The SpamAssassin team also recommends the use of sa_compile. To this end, you need to edit either the Spamd startup script or startup options, where you will find the -L ( -local) option. Also make sure the implementation of network tests is enabled. Therefore, you are best off removing these rules and replacing them with URIBL_WS_SURBL. The blacklist and blacklist-uri rules in particular are considered real performance brakes. The more rules SpamAssassin needs to process, the slower the environment will be. In principle, avoid rulesets that are larger than 100-150KB. SpamAssassin also provides various approaches. =_Part_890579_1702502143.The topic of performance tuning is a perennial favorite for all critical infrastructure components. Qer qwertyuasdfghjk fdfr frefre qwertyuasdfghjkdwedew dew dew X-ACL-Warn: SpamAssassin detected spam (from to Test posta 1 0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from 0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature fromĠ.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily 0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)Ġ.0 SPF_HELO_NONE SPF: HELO does not publish an SPF RecordĠ.0 HTML_MESSAGE BODY: HTML included in message 0.0 SPF_PASS SPF: sender matches SPF record The administrator of that system for details.Ĭontent preview: qer qwertyuasdfghjk fdfr frefre qwertyuasdfghjkdwedew dewĭew qer qwertyuasdfghjk fdfr frefre qwertyuasdfghjkdwedew dew dewĬontent analysis details: (6.8 points, 5.0 required)Ġ.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
Message has been attached to this so you can view it or label Has identified this incoming email as possible spam. X-Spam-Report: Spam detection software, running on the system "",
#Spamassassin rule iso
Surprise, although the body of the two e-mails is exactly the same, SpamAssassin did not detect the e-mail with the iso file attached as spam. In my second e-mail, I sent the same text again, but I included the iso file that SpamAssassin could not detect. In my first e-mail, I just sent the text and added the word qwertyuasdfghjk to be searched in the text. Then I sent test emails from my yahoo email account. I removed all the rules from local.cf and added a basic rawbody rule. But I noticed that SpamAssassin is not able to detect some emails. I checked the rules saved in local.cf, there is no problem. Recently I've been getting a lot of spam emails with the DHL_Tracking,pdf.iso file attached.
0 kommentar(er)
