I’ve decided to stop reporting spam to ISP’s.
It just seems like an incredible waste of effort on my part.
For YEARS now I’ve used SpamCop to report spam to ISP’s (both the mail provider and related web hosts) and have gotten very few non-automated responses.
It’s nice that many of the major mail providers give you the ability to report a message you’ve received as spam … but some of them make it far TOO easy to report something as spam.
I’ve noticed that many of the big names put the “Report as spam” button way too close to the delete button.
Let’s take a look at some of the providers …
As I mentioned before … even though I’m participating in Yahoo’s Email Complaint Feedback Loop, I’m still getting deferrals when trying to deliver mail to Yahoo’s mail servers. I’ve gotten a few complaints, but not nearly enough to really justify having mail delivery deferred.
I think I’ve figured out a bit more about why Yahoo’s mail servers are deferring some of the mail my servers try to deliver to them.
I’ve never understood the rationale behind the various web scripts that claim that they are ‘poisoning’ spammers lists.
They claim that, by putting a bunch of garbage email addresses on a web page and encouraging spammers to harvest the page, they are poisoning a spammers email list and thus making the list useless so that they will discard the list.
Where did they ever get the idea that spammers CARE about the good & bad addresses that they harvest. Considering how much it costs them to send spam, they wouldn’t are one lick if 90% of the addresses on their list is valid or not. Especially since most spam sent these days is done by infected personal computers controlled by ‘bot herders‘.
I often watch the log file on my mail server … and observe the servers trying to deliver mail to mangled and non-existent addresses. It’s clear the sending system is just blasting names at my server without any consideration if the address exists or not. My mail server software (sendmail) had an option to throttle the connection of any system that gets more than a certian number of bad addresses. I also have a script that monitors for that behavior and adds a firewall rule to completely block such systems.
My advice to those who create such scripts … focus your energies elsewhere … right now you’re just wasting your time.
Oh, by the way, for those of you who are trying to use “User-Agent” lists to block harvesters … don’t waste your time on that either. Harvesters, like spammers, will never clearly identify themselves as such … and will use a completely legitimate user agent when spidering your website. Additionally, they will absolutely ignore any robots.txt file that you have in your site.
There are, however, systems that use a somewhat similar technique to stop spammers … but are much more effective. Instead of just trying to poison a spammers list … they use traceable email addresses. This means that, when a harvester visits a page with this traceable email address, they log the IP the harvester is using and the email address that is harvested. This way, when spam is sent to the address, they know when and how the address was harvested and where it was sent from. Theoretically the spammer is reported both to the ISP that the mail was sent through AND the ISP that was used to harvest the address. Project Honeypot is one such anti-harvester organization.
Yesterday I found that the RPM database on my Fedora Core 6 linux system’s were corrupted and that the regularly running update process was failing (without telling me, unfortunately).
After fixing the RPM database problem (rm -f /var/lib/rpm/__db.* && rpm -vv --rebuilddb) and running the update (yum update), I found that SpamAssassin’s update process wasn’t working anymore.
root@rivendell ~]# sa-update
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Scalar/Util.pm line 30.
Apparently one of the updates that were applied in the mass update caused SpamAssassin to break.
The same problem occurred when I tried to test the SpamAssassin rules.
root@rivendell ~]# spamassassin --lint
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Scalar/Util.pm line 30.
A bit of research turned up this link.
Luckily the fix was fairly easy … just update the Scalar-List-Utils CPAN package …
perl -MCPAN -e 'install "G/GB/GBARR/Scalar-List-Utils-1.18.tar.gz"
… and everything worked fine again.
Recently I noticed that there’s a lot of temporary files in the /tmp directory on my mail server … all the files have spamassassin in the file name. I figured that in some cases, SpamAssassin (or programs it calls) isn’t cleaning up properly.
I whipped up this script that will clean up any spamassassin files & directories that are older than a set number of minutes (60 in my case)…
#!/bin/sh
AGE=60
if [ "$1" == "--test" ]
then
CMD="-exec echo"
echo "$0: test mode"
else
CMD="-exec"
fi
/usr/bin/find /tmp \
-mmin +$AGE \
-name spamassassin.ocr* \
$CMD /bin/rm -f '{}' \;
/usr/bin/find /tmp \
-maxdepth 1 \
-mmin +$AGE \
-type d \
-name .spamassassin\* \
$CMD /bin/rm -rf '{}' \;
If you run the script with a parameter of ‘–test’, it will just show the commands it would have executed.
I put the script in /etc/cron.hourly directory so it gets executed every hour.