Bleh, I hate spam…..
Well, I basically just followed the documentation. I don't think you have to go through as many steps simply because you are a low-traffic individual user type and can point directly to the Spamhaus servers for your sendmail dnsbl feature.
First, you need to open up your .mc file:
bash-# vi /usr/share/sendmail/cf/cf/config.mc
For yzzerdd.net running Slackware:
bash-# cd /usr/share/sendmail/cf/cf bash-# vi sendmail-slackware-yzzerdd.mc
Now we add in the FEATURE dnsbl:
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org',`"554 Rejected " $&{client_addr} " Your Custom Rejection Message"')dnl
, ” (comma) in your custom rejection message!
FEATURE(`access_db')dnl FEATURE(`delay_checks',`friend')dnl
Place that somewhere after your dnsbl FEATURE. Then save your changes to config.mc and:
bash-# cd /etc/mail bash-# vi access
You'll want to add each user who will receive spam to his/her own line in this file like so:
Spam:thisIsForTheRough@tough.org FRIEND
Now save your changes to the access file and type this sucka:
bash-# pwd /etc/mail bash-# makemap hash access < access
This should create the file access.db. Now all you have to do is rebuild your sendmail config file from the macro we previously edited. Which can be easily accomplished by:
bash-# cd /usr/share/sendmail/cf/cf/ bash-# ./Build config.cf
For yzzerdd.net running Slackware (the Build script is modified by Pat):
bash-# cd /usr/share/sendmail/cf/cf bash-# ./Build sendmail-slackware-yzzerdd.mc bash-# cp sendmail-slackware-yzzerdd.cf /etc/mail/sendmail.cf
That about does it. Restart sendmail so it can read your new configuration then you can use the test described here to see if you've set everything up correctly.
This is my addition to /usr/share/sendmail/cf/cf/sendmail-slackware-yzzerdd.mc:
dnl# Spamhaus filtering configuration
FEATURE(`enhdnsbl',`sbl-xbl.spamhaus.org',`"554 Rejected " $&{client_addr} " Thi
s email has been marked as spam. If you think this is an error email root@yzze
rdd.net from a different email server."')dnl
FEATURE(`access_db')dnl
FEATURE(`delay_checks',`friend')dnl
Add this to your sendmail.cf (/usr/share/sendmail/cf/cf/sendmail-slackware-yzzerdd.mc):
dnl# Sorbs filtering configuration
FEATURE(`dnsbl',`dnsbl.sorbs.net',`"554 Rejected " $&{client_addr} " found in dnsbl.sorbs.net"')dnl
From:user@whitelist.address OK
Add a line like the above for each email address you would like to whitelist to your access file. Then,
bash-# makemap hash access < access
while in /etc/mail, and restart sendmail.
Add an entry in /etc/mail/spamassassin/local.cf similar to the following:
whitelist_from *@sparkingwire.com
To enhance SpamAssassin's functionality, you should probably add some custom rulesets to your installation:
Figuring out where SpamAssassin was actually reading the rules from was tricky. Mostly because I'm using an install of FreeBSD where nothing is in the default directories. Adding to the confusion, the same rules were saved in two separate locations :'-( What's a boy to do. Well, this:
bash ~# spamassassin -D config --lint >& lint.txt
Obviously, sending the output to a .txt file is optional, but either way you'll be able to see the location of the rules SA is using.
Although it's nice to know where your rules are stored, the step above isn't really necessary if you follow these instructions.
Here's the contents of my channelfile, sare-sa-update-channels.txt:
70_sare_stocks.cf.sare.sa-update.dostech.net 70_sare_adult.cf.sare.sa-update.dostech.net 70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net 70_sare_evilnum0.cf.sare.sa-update.dostech.net 70_sare_evilnum1.cf.sare.sa-update.dostech.net 70_sare_genlsubj0.cf.sare.sa-update.dostech.net 70_sare_genlsubj1.cf.sare.sa-update.dostech.net 70_sare_genlsubj2.cf.sare.sa-update.dostech.net 70_sare_genlsubj_eng.cf.sare.sa-update.dostech.net 70_sare_header0.cf.sare.sa-update.dostech.net 70_sare_header1.cf.sare.sa-update.dostech.net 70_sare_highrisk.cf.sare.sa-update.dostech.net 70_sare_html0.cf.sare.sa-update.dostech.net 70_sare_html1.cf.sare.sa-update.dostech.net 70_sare_obfu0.cf.sare.sa-update.dostech.net 70_sare_obfu1.cf.sare.sa-update.dostech.net 70_sare_oem.cf.sare.sa-update.dostech.net 70_sare_random.cf.sare.sa-update.dostech.net 70_sare_specific.cf.sare.sa-update.dostech.net 70_sare_spoof.cf.sare.sa-update.dostech.net 70_sare_unsub.cf.sare.sa-update.dostech.net 70_sare_uri0.cf.sare.sa-update.dostech.net 70_sare_uri1.cf.sare.sa-update.dostech.net 70_sare_uri3.cf.sare.sa-update.dostech.net 70_sare_uri_eng.cf.sare.sa-update.dostech.net 70_sare_whitelist.cf.sare.sa-update.dostech.net 70_sare_whitelist_rcvd.cf.sare.sa-update.dostech.net 70_sare_whitelist_spf.cf.sare.sa-update.dostech.net 70_sc_top200.cf.sare.sa-update.dostech.net 72_sare_bml_post25x.cf.sare.sa-update.dostech.net 72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net 99_sare_fraud_post25x.cf.sare.sa-update.dostech.net updates.spamassassing.org
It's the ruleset suggested by OpenProtect which doesn't contain any of the really aggressive SARE rules. However, some spam is still coming through.
I just followed the steps at http://saupdates.openprotect.com/:OpenProtect, and will incorporate this into a script:
<code bash># sa-update –gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 –channel saupdates.openprotect.com</code>
setup crontab:
# crontab -e
and I added in:
# run sa-update every date at 8:30am 30 8 * * * /root/spam_update/sa-auto-update
setup the sa-auto-update script:
# vi /root/spam_update/sa-auto-update
and its contents:
#!/bin/bash /usr/bin/sa-update --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 \ --channel saupdates.openprotect.com --channel updates.spamassassin.org -D