Posted on

Spam from global switch

My spam traps pick up dodgy emails from all sorts, including large companies that ought to know better. But today one was hit with a marketing communication from Global Switch. Not from an errant client of the data centre, but from Global Switch themselves, marketing their rack space (half price for the first 12 months, apparently).

I’m not sure what to make of this, but if you’re thinking of starting up a spamming operation, Global Switch looks like the place to be. If they don’t care whether they’re using legitimate, opt-in lists, why should they hassle their customers. Needless to say I contacted them about it; needless to say there was no one available to comment. If anyone from Global Switch is out there, it’s still not too late.

Further:

I did get through to Global’s sales team. While they stopped short of condemning the practice, they said they’d investigate if I gave them enough information to identify the honeypot. I’m sure they’d wouldn’t have bought the list they used if they suspected it was dodgy, which just goes to show.

 

Posted on

Who needs a botnet when you can Yahoo?

Someone, somewhere is making full use of Yahoo webmail to send out  what could be millions of fake emails pretending to be Amazon order confirmations (extrapolating on the numbers received here). Needless to say, they really contain a ZIP file with a rather nasty looking Microsoft executable file inside.

My guess is they’re using accounts compromised earlier in the year, as reported here, which gets them through spam filters as most ISPs trust Yahoo. Actually, ISPs generally don’t trust Yahoo but their users don’t see it that way when their friends’ Yahoo email is blocked.

Is this Yahoo’s fault? Normally I’d blame the criminals, but in this case Yahoo could be doing a lot more to to help. This has been going on for three days, and there’s no legitimate reason why any of its users should be sending out with addresses @amazon.co.uk. Even if they can’t scan to detect the latest malware, recognising these fake emails is easy enough.

It’s hardly a new tactic by the criminals, of course. amazon.co.uk’s name was abused back in May to deliver similar Trojan malware.

It’s about time Yahoo (and other freemail services) took responsibility for the damage caused by their business model.

 

Posted on

New kind of distraction email bomb attack

AppRiver

I got an interesting note from AppRiver, in which Fred Touchette, one of their analysts explains a technique used by criminals, which they first noticed in January. I haven’t seen it, nor any evidence of specific cases, but it’s food for thought.

The idea is to mail-bomb a user with thousands of spam emails containing random content over a period of several hours. Mr Touchette’s theory is that this is done to cause the user to delete the whole lot unread, and in doing so to miss an important email from their bank or similar, and therefore fail to notice a fraud attempt.

I’m not so convinced about this MO to cover bank fraud, but it would certainly be useful to someone stealing a domain name. A registrar will contact the administrative contact with a chance to block the transfer of a domain when any attempt to move it is made. This is a weak system; banks would normally require positive confirmation and not rely on the receipt and reading of an email before doing anything drastic.

If the criminals have your email login, necessary to manage something like a bank account, they will have no need to prevent you from reading emails with a mail-bomb. They just have make sure they read and delete your mail before you do, which isn’t hard if they’re keen. AppRiver’s advice, nonetheless, is to call all your banks to warn them someone might be attempting to compromise your account. I’m sure they’ll thank you politely if you do.

You can read Appriver Threatscape Report for yourself. Most of it’s unsurprising if you follow threats yourself, but this detraction technique as an attack vector is worth taking seriously, regardless of its prevalence in the wild. AppRiver is based in Florida and provides web and email security and filtering services. I met them at a London trade show and they seemed like a decent bunch.

Posted on

Using MX records to create backup mail server

There’s a widely held misunderstanding about “main” and “backup” MX records in the web developer world. The fact is that there no such thing! Anyone who tells you different is plain wrong, but there are a lot of web developers who believe there is the case, and some ISPs give in and provide them as it’s simpler than arguing. It’s possible to use two MX records in some crazy scheme that looks like a backup server, in practice it does very little to help and quite possibly rather a lot to hinder. It won’t make your email more robust in practical terms.

If you are using an email server at a data centre, with reasonable expectation of an always-on connection, you need a single MX record. If your processing requirements are great you can have multiple records at the same level to spread the load between peered servers, but none would be a backup any more than any other. Senders simply get one server at random. I have a single MX record.

“But you must have a backup!”, is the usual response. I do, of course, but it has nothing to do with having multiple MX records. Let me explain:

A domain’s MX record gives the address of the server to which its email should be sent. In practice, this means the company’s mail sever; or if they have multiple servers, the incoming one. Most companies have one mail server address, and this is fine. If that mail server dies it needs to be repaired or replaced, and the replacement gets the same address.

But what of having a second MX record with an alternative, lower-priority server? It may sound good, but it’s nuts. Think about it – the company’s mail server is where the mail ends up. It’s where the users expect to log in and read it. If you have an alternative server, the mail will go there instead, but the user’s won’t be able to read it. This assumes that the backup is on a different site, available if only the first site goes down. If it’s on the same site it’s even more pointless, as it will be affected by the same connectivity issues that took the first one offline. Users will have their existing mail on the broken server, new mail will be on a different server, and you’ll be in a real bugger’s muddle trying to reconcile the two later. It makes much more sense to just fix the broken one, or switch in a backup at the same location and on the existing IP address. In extremis, you can change the MX record to point to a replacement server elsewhere.

There’s a vague idea that if you don’t have a second MX, mail will be lost. Nothing can be further from the truth. If your one and only mail server is off-line, the sender’s server will queue up the message and keep trying until it comes back – it will normally do this for a week. It won’t lose it. Most mail servers will report back to the sender if it hasn’t been able to get through for four hours, so they’ll know there’s a problem and won’t worry that you haven’t replied.

If you have two mail servers, one on a different site, the secondary server will start receiving emails when the first one goes off-line. It’ll just queue them up, waiting to forward them to the primary one, but in this case the sender won’t get notification of the delay. Okay, if the primary server is off-line for more than a week it will prevent mail loss – but why would the primary server possibly be off-line for a week – the company won’t function unless it’s repaired quickly.

In the old days of dial-up, before POP3 came in to being, some people did use SMTP in a way where a server in a data centre forwarded to the remote site when it connected. I remember Cliff Stanford had a PC mail client called Turnpike that did just this in the early days of Demon. But SMTP was designed for always-on connections and POP3 was designed for dial-up, so POP3 won out.

Let’s get real: There are two likely scenarios for having a mail server off-line. Firstly, the hardware could be dead. If so, get it repaired, and in less than a week. Secondly, the line to the server could be down, and this could be medium-term if someone with a JCB has done a particularly “good job” on it. This gives you a week to make alternative arrangements and direct the mail down another line, which is plenty of time.

So, the idea of having a “backup” MX is pointless. It can only send mail to an off-site server; it doesn’t prevent any realistic mail loss and your email ends up where your users can’t get it until the primary server is repaired. But is there any harm in having one if it makes you feel better?

Actually, in practice, yes. It does make matters worse. In theory mail will just pile up on a spare server and get forwarded later. However, this spare server probably isn’t going to be up to the same specification as the primary one. They never are – they sit there idling, with nothing to do nearly all the time. They won’t necessary have the fastest line; their spam and virus filtering will be out-of-date or non-existent and they have a finite amount of disk space to absorb mail. This can really matter if you end up storing and forwarding a large amount of spam, as is often the case these days. The primary server can be configured to discard it quickly, but this isn’t a job appropriate for the secondary one. So it builds up until it’s ancient and meagre disk space is exhausted, and then it tells the sender to give up trying due to a “disk full” error – and the email is bounced off in to the ether. It’d have been much better to leave it on the sender’s server is the first place.

There are other security issues to having a secondary server. One problem comes with spam filtering. This is best done at the end of the line; it’s not the place of a secondary server to determine what gets delivered and what doesn’t. For starters, it doesn’t see the corpus of legitimate emails, so won’t be so adept at comparing and sorting. It’s probably going to be some old spare kit that’s under-powered for modern spam processing anyway. However, when it stores and forwards it, the primary server will see it comes from a “friend” rather than a dubious source in a lawless part Internet. Spammers do use secondary MX records as a back door to get around virus and spam filters for this very reason.

You could, of course, specify and configure a secondary mail server to be up to the job, with loads of disk space to prevent a DoS attack and fully functional spam filters, regularly maintained and sharing Bayesian analysis data and local rules with the actual server. And then have this expensive resource sitting there doing nothing all day but converting electricity in to heat. Realistically, it’s not going to happen.

By now you may be wondering, if multiple MX records are so pointless, why they exist? It’s one of these Internet myths; a paradigm that users feel comfortable with, without questioning the technology behind it. There is a purpose, but it’s not for “backup”.

When universal Internet email was new, messages would be sent to a user “@” computer, and computers were normally shared, so each would have multiple possible users. The computer would receive the email and put it in the mailbox corresponding to the user part of the address.

When the idea of sending email to a domain rather than a specific server came in to being, MD and MF records also came in to being. A MD record gave the IP address of the server where mail should end up (the Mail Destination). An MF record, if it existed, allowed the mail to be forwarded through another machine first (Mail Forward). This was sometimes necessary, for example if the MD was on a dial-up connection or behind a firewall and unable to accept direct connections over the Internet. The mail would go to the MF instead, and the MF would send it to the MD – presumably by batching it up and opening a line, transiting a firewall or using some other non-public mechanism.

In the mid 1980’s it was felt that having both MD and MF records placed double the load on DNS servers, so unified MX records, which could be read with a single lookup, were born. To allow for multiple levels of mail forwarding through firewalls, they were prioritised to 99 levels, although if you need more than three for any scheme you’re just being silly.

Unfortunately, the operation of MX records, rather than the explicitly named MF and MD, is a bit subtle. So subtle it’s often very misunderstood.

The first thing you need to understand is that email delivery should be controlled from the DNS for the domain, NOT from the individual mail servers that exist on that domain. This may not be obvious, but this is how it’s designed to work, and when you think of it, a central point of control is a good thing.

Secondly, DNS records should be universal. Every computer on the Internet, making the same DNS query, should get the same result. With the later addition of asymmetric NAT, there is now an excuse for varying this, but you can come unstuck if you get it wrong and that’s not what it was designed for.

If you want to reconfigure the route that mail takes to a domain, you do it by editing the single master DNS record (zone file) for that domain – you leave the multiple mail servers alone,

Now consider this problem: an organisation (called “theorganisation”) has a mail server called A. It’s inside the theorganisation’s firewall, for its own protection. Servers on the Internet can’t talk to A directly, because the firewall won’t let them through, but local users send and receive mail through it all day long. To receive external mail there’s another server called B, this time outside the firewall. A rule on the firewall allows specific traffic from B to get to A. The relevant part of the zone file may look something like this (at least logically):

MX 1 A.theorganisation
MX 2 B.theorganisation

So how do these simple lines tell the world, and servers A and B, how to operate? You need to understand the rules…

When another server, which I shall call C, sends a message to alice@theorganisation it will look up the MX records for theorganisation, and see the records above. C will then attempt to contact alice at the lowest numbered MX it finds, which points to server A. If C is located within the same department, it will be within the firewall and mail can be delivered directly; otherwise the firewall will block it. If C can’t contact A because of the firewall it will try the next highest on the list, in this case B. B is on the Internet, and will accept connections from C (and anyone else). The message arrives at B for Alice, but alice is not a user of B. However, B knows that it’s not the final destination for mail to theorganisation because the MX record says there’s a lower numbered server called A, so it attempts to forward it there. As B is allowed through the firewall, it can deliver the message to A, where it’s finally put in alice’s mailbox.

This may sound a bit complicated, but the rules for MX records can be made to route mail through complex paths simply by editing the DNS zone file, and this is how it’s supposed to work. The DNS zone file MX records control the path the mail will take. If you try to use the system for some contrary purpose (like a poor-man’s backup), you’re going to come unstuck.

There is another situation where you might want multiple MX records: If your mail server has multiple network interfaces on different (redundant) lines. If the MX priority value is the same for both, each IP address will (or should) be used at random, but if you have high-cost and low-cost lines you can change the priority to favour one route over another. With modern routing this artifice may not be necessary – let the router choose the line and mangle the IP addresses in to one for you. But sometimes a simple solution works just as well.

In summary, MX record forwarding is not designed for implementing backup mail servers and any attempt to use them for the purpose is going to do more harm than good. The ideas that this is what they’re all about is a myth.

 

Posted on

Cybercriminals: Microsoft’s X-EIP is your friend.

Since January 2013, and without any fanfare, Microsoft has stopped including the originating IP address of Hotmail emails in the headers. Instead, an ominously named X-EIP has appeared in its place, consisting of random characters.

Originating IP addresses are the only means to verifying the source of an email. This is important to prevent fraud, detect crime and block spam. It can’t be used by a recipient to positively identify a sender, but by contacting the relevant ISP about it, the location can be pinpointed relatively quickly and the ISP can take action against a customer based on a complaint. Even home users can check that the IP address their friend’s email came from is in the right country, rather than a cyber-café in some remote and lawless part of the world.

So why has Microsoft done this? After much waiting for a reply, this is the best I have got:

My name is **** and I am a Senior Support Analyst for Microsoft. I am part of the Hotmail Escalations Team handling this issue.

In the pursuit of protecting the privacy of our users, Microsoft has opted to mask the X-Originating IP address. This is a planned change on the part of Microsoft in order to secure the well-being and safety of our customers.

Microsoft is in the path of continuously improving the online safety and security of its users. Any feedback regarding this concern would be treated with utmost attention.

We appreciate your patience and understanding regarding this matter.

Thank you.
Best Regards, etc.

Note the “wellbeing and safety of [their] customers” in the above. Which of their customers need this protection? Well paedophiles wishing transfer material with their mates anonymously will love it. As will fraudsters, cyber-bullies and anyone else wishing to send untraceable emails.

Having analysed the new encrypted codes, they’re not a one-to-one encryption of an IP address. Two emails from the same address will have different codes, so decoding them won’t be easy at all. It’s likely that it’s a one-way hash, meaning Microsoft will need to go back through its records to find out where an email came from, and they’re only going to do that with a court order, I suspect.

And that’s not good enough – tracking cybercrime is an immediate activity, so such things can be shut down quickly. The Internet is self-policing; there’s no time for court orders, and no point if you’re crossing international boundaries. If you know the IP address some malware came from, it’s possible to get hold of the sender’s ISP and have the feed quenched within minutes, or if coming from a commercial or academic institution, the network administrators could be around to catch them in the act. Microsoft has extended this process from minutes to weeks, losing any reputation for responsibility it had with Hotmail (not much I’ll grant you) and promoting its service to the cyber criminal.

However, Microsoft is not alone. Google has been doing this for years with Gmail. Is this a cynical attempt by Microsoft to follow Google’s shameful lead?

There are some cases where anonymous email is a good idea, such as when sending emails from a country where free speech is aggressively discouraged. There is no need for this with a mainstream email service; it’s just a feature provided to encourage new users with something to hide.

 

Posted on

Spamhaus vs. Cyberbunker

There’s a real, genuine cyber-war going on over the Internet between Spamhaus and a Dutch company called Cyberbunker, and their connectivity provider A2B Internet. Spamhaus is a not-for-profit organisation that blacklists internet service providers that allow spammers to use their facilities, and Cyberbunker is an ISP which, according to their own web site, provides services to anyone for any purpose “except child porn and anything related to terrorism. Everything else is fine.” Spamming is okay by them; they’ve never denied it and basically take the view that all ISPs dealing with spammers: it’s none of Spamhaus’ business what they do and launching a denial-of-service attack against them is some kind of natural right. They’re known for hosting outfits like Pirate Bay when no one else would touch them, to give you some idea.

Pirate Bay
One of Cyberbunkers more high-profile customers – The Pirate Bay.

The war started on 19th March when a DDOS attack was launched against the Spamhaus servers in retaliation for them adding a range of IP addresses provided to Cyberbunker by A2B Internet.

A2B Internet’s view is that they’re not responsible for what Cyberbunkers’ customers do with the IP addresses and it’s no business of Spamhaus what anyone else on the Internet does. Spamhaus, and the users of the Spamhaus block-list (SBL) think it is, and after all, no one is forced to use the SBL – they use it to identify emails coming from outfits of the type often hosted by Cyberbunker. This didn’t stop A2B Internet going to the Dutch Police in outrage, accusing Spamhaus of extortion by blacklisting some of its IP addresses. Quite how this amounts to extortion isn’t clear. It pressures A2B  on who it sells connectivity to Cyberbunker, to stop doing so, but Spamhaus would argue that it was listing IP addresses used to send spam, and that’s all there is to it.

Although the SBL isn’t easy to disable by such methods, it was nonetheless annoying and Spamhaus called on the services of Californian-based CloudFlare to mitigate the attacks, which promptly got attacked themselves for their trouble. The attackers are using a feature of DNS to send gigabits of traffic towards the Spamhaus servers. Using a botnet, they’re sending zone transfer requests to poorly configured DNS servers claiming that Spamhaus has requested data on a zone (domain). The request is short, but the data returned can be very large and is sent directly to Spamhaus. People running a DNS should configure it such that it won’t accept zone transfer requests from “just anyone”, but many fail to do this – especially Microsoft installations, in my experience. By using a botnet to send the initial request the attackers have been generating traffic said to be in excess of 300Gbps.

But these attacks don’t just affect Spamhaus. The DNS servers hijacked for the purpose are consequently over-loaded when legitimate requests get through, and the traffic heading to Spamhaus is going to squeeze other legitimate traffic en route. There are stories about concerning disruption to Netflix and other high-bandwidth Internet services. Whether this is any great loss is a matter of opinion.

But is it fair to blame Cyberbunker for these attacks? Circumstantially they’re implicated. The New York Times quoted “Internet Activist” Sven Olaf Kamphuis, who claims to speak for the attackers, as saying that Cyberbunker was retaliating against Spamhaus for “abusing their influence using  one of the largest DDoS attacks the world had publicly seen.” However, it’s my understanding that Mr Kamphuis is the actually the Managing Director, and possibly owner, of Cyberbunker – so if the comments in the NYT are correct, it’s clearly them.

Kamphuis continued, “Nobody ever deputized Spamhaus to determine what goes and does not go on the Internet, they worked themselves into that position by pretending to fight spam.”

He has a point, but possibly not a very good one. About 75% of the spam filters in the world use the SBL to drop mail from dodgy sources. They don’t have to; they choose to. If the SBL was no good, they wouldn’t use it. It’s not really a case of Spamhaus determining what goes on the Internet, it’s a case of the majority of the Internet trusting Spamhaus more than they do Cyberbunker when it comes to deciding what’s spam and what isn’t.

But it means that the maintainers of the SBL have a lot of power, because incorrectly listing an IP address has a seriously negative effect on its owner. It depends on your point of view as to whether a listing is deserved or not. Spammers say they’re within the law (or their moral rights); the recipients of their marketing messages may disagree.

Cyberbunker
Cyberbunker is what its name suggests: a data centre in a disused NATO bomb-proof bunker

This disagreement has been going on for years, but A2B Internet’s complaint to the police and the subsequent DDoS attack are probably a game changer. They’ve crossed a line and “the authorities” can no longer ignore Cyberbunker’s activities. Subsequent action could be interesting as Cyberbunker’s own web site boasts of them already having defeated a raid by a Dutch “SWOT team” – a bunch of heavily armed police with battering rams at least. As they’re holed up in an old NATO nuclear bunker with blast doors able to withstand a 20 Megaton atomic bomb, a bunch of coppers with a sledge hammer aren’t going to have much effect.

Turning off the up-stream link might, however, have the desired effect. They may have buried themselves with enough food, water and diesel for their generators to withstand a long siege, but there’d be no point once they’d been disconnected. I understand that A2B Internet have decided to turn off the tap already. According to Spamhaus, Cyberbunker is getting feeds from elsewhere, but on checking they’re not terribly good feeds – or someone is currently attacking Cyberbunker.

As to the collateral damage, I suspect it’s being somewhat over-blown. Operators of a DNS server should configure it properly to prevent this nonsense, and ISPs really ought to take the initiative and check their customers are secure. But this could be a seminal event where spammers are concerned, and the world will be watching the Dutch authorities with interest.

And before condemning Cyberbunker completely, it’s worth noting they’re providing hosting for legitimate users being hounded by illegitimate governments around the world. In principle, they’re possibly as often right as they are wrong by ignoring what their customers do. There’s reputedly a lot of cyber-crime taking place on AWS, don’t forget, and the world isn’t clamouring to shut Amazon down. The difference may only be scale.

Posted on

Dodgy “bulk email” operators

I’m forever receiving emails from “bulk email” companies that claim to be “opt-in” but are using addresses that are culled from elsewhere. The elsewhere basically means they’re not real email addresses and could not possibly have been the subject of an opt-in.

After replying to these with an unsubscribe request (on the assumption that they might be legitimate, but have accidentally purchased a dodgy list) I though I’d list them here if the emails don’t stop.

If your name is on this list and you think you’re innocent and can prove it, it will, of course, be removed. If the mail header shows it’s coming from your server and you’ve ignored unsubscribe requests you can explain why. Your protestations will be published along with the other evidence, and Internet users can decide your innocence or guilt.

05th June 2012 Tech Users Centre, Inc. 60 Cannon St. London
05th June 2012 mynewsdesk.com
05th June 2012 Simply Media Network, LTD., 48 Charlotte St, London (aka Comunicado Limited 6/43 Bedford St)
03rd June 2012 panopticsi.com
02nd June 2012 Marketing Empire UK (websitedesigncity.co.uk)
01st June 2012 quickmailing.co.uk (Smilepod, 23 Rose Street
Covent Garden )
01st June 2012 Comunicado Limited 6/43 Bedford St
01st June 2012 domainmail (on behalf of Insured Health)
31st May 2012 National Training Resources Limited
31st May 2012 backbonemarketing.co.uk, backboneconnect.co.uk PO Box 4380 Tamworth.
31st May 2012 Comunicado Limited 6/43 Bedford
29th May 2012 Nuance Communications
25th May 2012 Comunicado Ltd, 6/43 Bedford Street
24th May 2012 Oxeta
24th May 2012 www.datadeals.co.uk
24th May 2012 Comunicado Limited
22nd May 2012 Accountingoffice.co.uk, 199 New Road, Skewen
16th May 2012 Consulmax (emaila-company.co.uk)
16th May 2012 domainmail (webdoctor.org)
11th April 2012 Easymailit.com

Posted on

What is all this Zune comment spam about?

People running popular blogs are often targeted by comment spammers – this blog gets hit with at least 10,000 a year (and very useful for botnet research) – most of it is semi-literate drivel containing a link to some site being “promoted”. Idiots pay other idiots to do this because they believe it will increase their Google ranking. It doesn’t, but a fool and his money are soon parted and the comment spammers, although wasting everyone’s time, are at least receiving payment from the idiots of the second part.

But there’s a weird class of comment spam that’s been going for years which contains lucid, but repeated, “reviews” about something called a “Zune”. It turns out that this is a Microsoft MP3 player available in the USA. The spams contain a load of links, and I assume that the spammers are using proper English (well, American English) in an attempt to get around automated spam filters that can spot the broken language of the third-world spam gangs easily enough. But they do seem to concentrate on the Zune media player rather than other topics. Blocking them is easy: just block any comment with the word “Zune” in, as it doesn’t appear in normal English. Unless, of course, your blog is about media players available in the USA.

This really does beg the question: why are these spammers sicking to one subject with a readily identified filter signature? I’ve often wondered if they’re being paid by a Microsoft rival to ensure that the word “Zune” appears in every spam filter on the planet, thus ensuring that no “social media” exposure exists for the product. Or is this just a paranoid conspiracy theory?

An analysis of the sources shows that nearly all of this stuff is coming from dubious server hosting companies.  A dubious hosting company is one that doesn’t know/care what its customers are doing, as evidenced by continued abuse and lack of response to complaints. There’s one in Melbourne (Telstra!) responsible for quite a bit of it, and very many in South Korea plus a smattering in Europe, all of which are “one-time” so presumably they’re taking complains seriously even if they’re not vetting beforehand. It’s hard to be sure about the Koreans – there are a lot but there’s evidence they might be skipping from one hosting company to the other. Unusually for this kind of abuse there are very few in China and Eastern Europe, and only the odd DSL source. These people don’t seem to be making much use of botnets.

So, one wonders, what’s their game? Could it be they’re buying hosting space and appearing to behave themselves by posting reasonable-looking but irrelevant comments? Well any competent server operators could detect comment posting easily enough, but in the “cheap” end of the market they won’t have the time or even the minimal knowledge to do this.

I did wonder if they were using VPN endpoints for this, but as there’s no reverse-lookup in the vast majority of cases it’s unlikely to be any legitimate server.

Posted on

Spamassassin, spamd, FreeBSD and “autolearn: unavailable”

I recently built a mail server using FreeBSD 8.2 and compiled spamassassin from the current ports collection, to run globally. spamd looked okay and it was adding headers, but after a while I noticed the Baysian filtering didn’t seem to be working in spite of it having had enough samples through.

A closer look at the added headers showed “autolearn: no”, or “autolearn: unavailable” but never “autolearn: ham/spam”.

What was going on? RTFM and you’ll see spamassassin 3.0 and onwards has added three new autolearn return codes: disabled, failed and unavailable. The first two are pretty self-explanatory: either you’d set bayes_auto_learn 0 in the config file or there was some kind of error thrown up by the script. But I was getting the last one:

unavailable: autolearning not completed for any reason not covered above. It could be the message was already learned.

I knew perfectly well that the messages hadn’t already been learned, so was left with “any reason not covered by the above”. Unfortunately “the above” seemed to cover all bases already. There wasn’t any clue in /var/maillog or anywhere else likely.

I don’t much care for perl scripts, especially those that don’t work, so after an unpleasant rummage I discovered the problem. Simply put, it couldn’t access its database due to file permissions.

The files you need to sort are at /root/.spamassassin/bayes_* – only root will be able to write to them, not spamd – so a chmod is in order.

A better solution is to move the Bayesian database out of /root – /var would probably be more appropriate. You can achieve this by adding something like this to /etc/spamd.cf (which should link to /usr/local/etc/mail/spamassassin/local.cf):

bayes_path /var/spamassassin/bayes/bayes
bayes_file_mode 0666

I suspect that the lower-security Linux implementation avoids these problems by setting group-write-access as default, but FreeBSD, being a server OS, doesn’t. It’s also a bug in the error handling for the milter – it should clearly report as a “failed” and write something to the log file to tell you why.

You should be able to restart spamd after the edit with /usr/local/sbin/spamdreload, but to be on the safe side I use the following after shutting down Sendmail first.

/usr/local/etc/rc.d/spamass-milter restart
/usr/local/etc/rc.d/sa-spamd/restart

I don’t know if Sendmail can cope well with having spamass-milter unavailable, but why take the risk?

 

Posted on

Comment spam from Volumedrive

Comment spammers aren’t the sharpest knives in the draw. If they did their research properly they’d realise that spamming here was a stupid as trying to burgle the police station (while it’s open). You’ll notice there’s no comment spam around here, but that isn’t to say they don’t try.

Anyway, there’s been a lot of activity lately from a spambot running at an “interesting” hosting company called Volumedrive. They rent out rack space, so it’s not going to be easy for them to know what their customers are doing, but they don’t seem inclined to shut any of them down for “unacceptable” use. For all I know they’ve got a lot of legitimate customers, but people do seem to like running comment spammers through their servers.

If you need to get rid of them, there is an easy way to block them completely if you’re running WordPress, even if you don’t have full access to the server and its firewall. The trick is to over-ride the clients Apache is prepared to talk to (default: the whole world) by putting a “Deny from” directive in the .htaccess file. WordPress normally creates a .htaccess file in its root directory; all you do is add:

Deny from bad.people.com

Here, “bad.people.com” is the server sending you the spam, but in reality they probably haven’t called themselves anything so convenient. The Apache documentation isn’t that explicit unless you read the whole lot, so it’s worth knowing you can actually list IP addresses (more than one per line) and even ranges of IP addresses (subnets).

For example:

Deny from 12.34.56.78
Deny from 12.34.56.89 22.33.44.55
Deny from 123.45.67.0/24

The last line blocks everything from 123.45.67.0 to 123.45.67.255. If you don’t know why, please read up on IP addresses and subnet masks (or ask below in a comment).

So when you get a a load of spammers from similar IP addresses, look up to see who the block belongs to using “whois”. Once you know you can block the whole lot. For example, if you’re being hit by the bot using Volumedrive on 173.208.67.154, run “whois 173.208.67.154”. This will return:

NetRange: 173.242.112.0 - 173.242.127.255
CIDR: 173.242.112.0/20
OriginAS: AS46664
NetName: VOLUMEDRIVE
NetHandle: NET-173-242-112-0-1
Parent: NET-173-0-0-0-0
NetType: Direct Allocation
<snip>

If you don’t have whois on your comptuer (i.e. you’re using Windoze) there’s a web version at http://www.whois.net/.

In the above, the CIDR is the most interesting – it specifies the block of IP addresses routed to one organisation. I’m not going in to IP routing here and now, suffice to say that in this example it specifies the complete block of addresses belonging to volumedrive that we don’t want – at least until they clean up their act.

To avoid volumedrive’s spambots you need to add the following line to the end your .htaccess file:

Deny from 173.242.112.0/20

If this doesn’t work for you the the web server you’re using may have been configured in a strange way – talk to your ISP if they’re the approachable type.

I have contacted Volumedrive, but they declined to comment, or even reply; never mind curtail the activities of their users.

This isn’t a WordPress-only solution – .htaccess belongs to Apache and you can use it to block access to any web site.

Perhaps there’s some scope in sharing a list these comment spambots in an easy-to-use list. If anyone’s interested, email me. This is a Turing test :-)