Posts filed under 'Email'
We released Apache SpamAssassin 3.2.3 two weeks ago. So far there have been only a couple people who have indicated they’ve had problems with this release, so I’d say that the current stable branch is back to normal. Along with fixes for things broken in the last couple of releases, 3.2.3 also improves some rules to avoid false positives on ham sent from some Windows Vista mail clients, avoids FP’ing on static clients in the rule RDNS_DYNAMIC, and makes sure that code isn’t run for eval rules when their score is zeroed saving you CPU time.
August 27th, 2007
In our on-going efforts to break something in the stable branch every couple of months, we released Apache SpamAssassin 3.2.2 this week. It fixes a few bugs, including the inability to install SpamAssassin 3.2.1 via CPAN using sudo — at least for some Perl versions on some platforms. On some platforms with some Perl versions, most commonly Perl 5.6.1, spamd might not be able to setuid (ie., drop root privs) and proceed to continuously kill its children when they end up attempting to run as root. So if you want to upgrade to 3.2.2 make sure that you can run “make test” as root before installing the software. If make test as root fails you’d be best off waiting for 3.2.3.
July 28th, 2007
After being told that “SmartScreen technology” had blocked his server from sending mail to Hotmail, this guy found that if he used Outlook 2003, rather than Thunderbird, he could get his mail delivered. Not that you should be surprised by that. It’s not like Microsoft client headers appear in a whole lot more spam than Mozilla headers. Oh wait a second, Microsoft headers do appear in at least half of all spam.
http://www.theregister.co.uk/2007/06/15/spam_nothotmail/page2.html
“I started playing around with clients rather than concentrating on server setup, and I’ve had some interesting results. I can send to Hotmail without a problem using Outlook 2003, but no cigar with Mozilla Thunderbird. I think that this suggests that the headers the email clients add to an email also play a crucial role in determining if the mail gets through or not. This is BAD news because as a system admin there is generally very little you can do about this.”
June 20th, 2007
We released new versions of SpamAssassin for both the 3.1 and 3.2 branches on Monday. 3.1.9 pretty much just includes the fix for CVE-2007-2873 (which only affects people who using the spamd –allow-tell or -l option) while 3.2.1 has a few additional fixes. Specifically 3.2.1 fixes a bug that caused the included URIBL.com (who are still under a severe DDoS attack, BTW) tests from working along with a handful of things that affect various non-default setups. Some more fixes (for problems most people will never see) to the spamd pre-forking server are also included.
Unfortunately you can’t successfully run make test as root in 3.2.1 due to the fix for bug 5480. This makes installing SA 3.2.1 via CPAN, um, difficult. I never noticed this since I always build from source as a non-root user. I don’t think any vendors, like RedHat, noticed it either since they probably all do the same thing.
If you normally install SA via CPAN, my advice would be to stick with 3.2.0 for now, avoid doing anything that triggers the local symlink vulnerability described in CVE-2007-2873 and just run sa-update to get most of the rule fixes included in 3.2.1. I expect that there will be a 3.2.2 release in a month or so.
June 13th, 2007
In case you ever needed evidence that URI blacklists are effective or that spammers don’t like Spamhaus, you’ve now got a DDoS SYN flood attack to back up that argument.
The web mirrors for the three sites have been down for most of the day due to what’s reported by URIBL as “heavy syn floods for anyone operating a web mirror for uribl, surbl, or spamhaus”.
The SpamAssassin Rules Emporium (SARE) website is also down. It is hosted on one of the URIBL mirrors.
As of tonight, Spamhaus’ website is back up and running on a new IP.
I’m really surprised that this didn’t happen a lot sooner.
June 6th, 2007
For those of you who missed it, we released Apache SpamAssassin 3.2.0 on May 2nd after a few RCs and a bit of pestering people to test it out. Most of the bugs people encountered in the final release were with their integration software not adhering to API requirements that haven’t changed in ages. There’s a few other bugs that will be fixed in a soon to be released (I hope) 3.2.1… nothing of major concern to most people that would prevent you from upgrading to 3.2.0 now though.
Justin Mason outlined a number of key features introduced in 3.2.0 in his posting here. Two other things I’d add off the top of my head are the support of Mail::SPF which is the current SPF reference implementation (it does away with a lot of legacy crude present in Mail::SPF::Query and generally works a lot better) and the new “whitelist_auth” option that allows a user to whitelist a sender that passes any of DKIM, DomainKeys or SPF. It’s basically whitelist_from_dkim, whitelist_from_dk and whitelist_spf all rolled into one. The benefit is that an end-user doesn’t have to know which (or keep track of changes in which) form of email auth a user/domain is using.
It looks like I was pretty close on calling the release time frame too. In this post, on September 1, 2006, I guessed at late winter or early spring. I went skiing the last week of April and we released during the first week of May. Can’t get much better than that! I just hope I didn’t delay the release on some subconscious level.
Oh, the newest release of SpamAssassin will catch more spam (than older versions) for you too. Go figure.
May 27th, 2007
…and it does. Below is the header from a mail generated by an “email this tracking page to somebody” web request via their website. WTF is “+0000 (EST)” in the Date field value. Really. Is it Canada Post that sucks, SAP, or both. Well I know for the most part Canada Post sucks and, well, SAP sucking on this point wouldn’t surprise me at all.
This really reinforces my feeling that their panic inspired product e-Post probably sucks and is likely prone to getting caught up in anti-spam systems.
In any case, being dumb costs you. For this stupidity SpamAssassin awards you with:
50_scores.cf:score INVALID_TZ_EST 2.601 2.065 2.265 2.696
50_scores.cf:score DATE_IN_PAST_03_06 2.299 1.394 1.306 0.044
Which is:
4.9 for set 0 — which lucky for them is the only thing that hits in set 0.
3.459 for set 1 — it’s a good thing the body is formatted to avoid checksum database hits.
Set 2 and 3 scores are pretty safe as long as the user’s bayes database doesn’t take off in the wrong direction (I hit BAYES_50).
Oh yeah, they forge the mail from: too! Idiots.
Return-Path: <sender@example.net>
Received: from OT1LF900.CPC (mailoutcpc.canadapost.ca [66.110.6.70])
by mx-04.dostech.net (8.13.8/8.13.8) with SMTP id l4FKMgXq005778
for <recipient@example.com>; Tue, 15 May 2007 16:22:43 -0400
Received: from (10.130.62.19) by OT1LF900.CPC via smtp
id 0969_7d2e5b8a_034c_11dc_8ee3_0002b3da1013;
Tue, 15 May 2007 21:26:36 -0400
Received: from canadapost.ca ([10.100.21.29]) by cpcw1003.cpggpc.ad with Microsoft SMTPSVC(6.0.3790.211);
Tue, 15 May 2007 16:22:42 -0400
Date: Tue, 15 May 2007 16:22:41 +0000 (EST)
From: sender@example.net
Subject: =?iso-8859-1?Q?Event_Notification_/_Avis_d’activit=E9?=
To: recipient@example.com
Reply-To: sender@example.net
Message-ID: <ADR32000002408715@canadapost.ca>
MIME-Version: 1.0
Importance: Normal
X-Priority: 3 (Normal)
X-Mailer: SAP Web Application Server 6.40
Content-Type: text/plain;
charset=”iso-8859-1″
Content-Description:
=?iso-8859-1?Q?Event_Notification_/_Avis_d’activit=E9?=
X-OriginalArrivalTime: 15 May 2007 20:22:42.0226 (UTC) FILETIME=[CA55D120:01C7972E]
May 15th, 2007
Apache SpamAssassin 3.1.8 was released on Wednesday. It would be a good idea for most people to update — especially those processing a lot of mail for a lot of users/domains. People using sa-update with channels from sources that they don’t particularly trust to adequately secure their channel to prevent it being compromised should also update. With versions prior to 3.1.8 a channel, that you use, compromised by a malicious party could turn your SpamAssassin install into a spambot (or anything else that could be done with privs sa-update or other SA software runs as on your machine). Cool. The spambot possibility is the reason I pushed for the new –allowcode option (disabled by default).
Speaking of sa-update channels. People using the “Openprotect” channel are shit-out-of-luck for now if they’re using 3.1.8. Apparently they publish a separate txt record for each version of SpamAssassin. Actually, it’s not even each version of SA that supports sa-update — only versions 3.1.3-3.1.7 are currently supported by their channel. I suspect that their free DNS provider (speaking of not totally secure channels — make sure you’re not disabling the gpg key check for this channel since they outsource their DNS) doesn’t allow wildcards. I don’t know why they wouldn’t anticipate new releases in advance, though, and add records for, say, versions up to 3.1.15, or at least one more than the version number in current release.
Oh yeah… people using the “Openprotect” channel may or may not be affected by the new “–allowcode” thing in sa-update. The “Openprotect” folks decided to enable 12 plugins for you in their updates. Some of these plugins aren’t enabled by default in the SA distro and sa-update now won’t load these plugins (using the loadplugin lines in the updates, anyway) without you including the “–allowcode” option in your call to sa-update. Depending on whether or not their rule files include the proper “ifplugin” lines the channel might not pass a lint (and thus not be installed) if you haven’t loaded the required plugins yourself in your system config (which sa-update now uses to load the plugins you’ve enabled in your setup when linting an update).
Now that I’ve probably pissed off everyone involved with the “Openprotect” channel and all those who use it (really that’s not my intention — I’m trying to give people a heads up so that they don’t waste a bunch of time trying to figure out what’s going on) I’ll point out that the SARE sa-update channels that I provide aren’t at all affected by any of this. My channels are also a lot more flexible… you get to pick your own rulesets. See this page for usage details or this post for why I set these channels up.
February 15th, 2007
Looking at my httpd logs for the sa-update channel for SARE’s 70_sc_top200.cf that I host at 70_sc_top200.cf.sare.sa-update.dostech.net (howto), I’m wondering why about 25% of the IPs (and about 17% of the /24s) use it. If you’re running network tests SpamAssassin already queries SpamCop by default, so if you’re also using this channel (or ruleset via RDJ directly from SARE) you’re just adding a, usually outdated, copy of the same data you’re getting via DNS lookups.
My guess is that there’s a lot of people just not paying too much attention. I can’t imagine that there’s that many systems running without network tests, at least not on purpose (I know there’s a lot of people that think they’re using network test, or all the tests available to them, but don’t realize that their distro disabled network tests by default).
I mentioned that the SpamCop data in this channel/ruleset is usually outdated… here’s a list of the updates since the beginning of December (I don’t know why Fred hasn’t automated the updates, last I heard he was manually uploading the ruleset — which itself is generated automatically):
Dec 1 13:04 200612011100.tar.gz
Dec 1 19:04 200612011700.tar.gz
Dec 2 15:04 200612021300.tar.gz
Dec 2 16:04 200612021400.tar.gz
Dec 5 18:04 200612051600.tar.gz
Dec 6 14:04 200612061200.tar.gz
Dec 6 18:04 200612061600.tar.gz
Dec 9 13:04 200612091100.tar.gz
Dec 13 18:04 200612131600.tar.gz
Dec 23 16:04 200612231400.tar.gz
Jan 2 11:24 200701020900.tar.gz
Jan 8 10:24 200701080800.tar.gz
Jan 9 12:24 200701091000.tar.gz
The update frequency is just weird… in the past I’ve noticed that it is sometimes updated three times in the span of two hours and then not updated again for weeks.
January 11th, 2007
I’ve known of Rogers doing this for years, but of course, I forgot all about it until it happened to me.
About a month ago I was having problems with a Linksys WRT54G locking up sporadically. Knowing some of the Linksys $10 routers have had issues under load, probably running out of memory or something, I configured a server running a SpamAssassin daemon (spamd) to forward all of it’s DNS queries to the DNS server assigned by Rogers via DHCP in an attempt to decrease the amount of state data the router had to keep track of for all the UDP queries.
That seemed to help a little, but not much, a firmware update released in December seems to have fixed it, but that’s besides the point.
The problem with using Rogers’ DNS server is that they run a script on their query log that looks for clients who send a lot of queries that result in NXDOMAIN, indicating a machine that could be a spam zombie or otherwise infected by malware. The problem is that the script doesn’t care what the queries were for, just that they returned NXDOMAIN. So if you’re using SpamAssassin, or any other anti-spam method, and are using any sort of DNSBL, you’re going to end up getting a lot of NXDOMAIN results. Specifically, you’re going to get lots of them for every message you check.
So anyway, without any notice (of course), Rogers disabled the highspeed internet service to the cable modem this was all sitting behind. After spending two hours on hold waiting to talk to someone, I managed to (a) get them to re-activate the service, (b) tell the poor guy who insisted I try and get a position in their networking department why what they were doing was a pretty good idea, but could be implemented better, and (c) find out that the threshold for NXDOMAIN query results in a single day is really low, as in “like way less than 300″. For someone filtering their own mail to one or two addresses, it’ll probably only take them a few minutes (and certainly no more than an hour) to hit 300 NXDOMAIN results. I know that mail to just my personal domain will trigger than in only a few seconds.
Once the service was re-activated, I configured Bind to forward all queries to my own DNS servers which have a huge cache or “spam query” results (so it’s probably faster than just doing the queries recursively on this low volume machine).
Anyway… Rogers could do better by paying attention to the number domains that are causing the NXDOMAIN results. In my case, all of the NXDOMAIN results were in response to queries to only a half dozen domains, like multi.surbl.org and multi.uribl.com. Certainly not a pattern consistent with a spam zombie — at least not an effective one (it could be one who’s master host/domain has been kicked off the net). I’d think that the trade off in not detecting infected, but ineffective, hosts over the false positives in cases like mine would be acceptable, especially considering that Rogers blocks port 25 in and out — which is great.
Anywho… if you’re a Rogers Highspeed Cable Internet customer, and you’re running SpamAssassin, or whatever, or do a lot of DNS queries for some other reason, I’d avoid using their DNS servers if you want to avoid having your connection disabled.
December 31st, 2006
Next Posts
Previous Posts
