Tuesday, 10 October 2006

There May be Troubles Ahead (for Spamhaus)

But while there's moonlight, and music, and love, and romance...

I'm reading some misinformed comment about the latest Spamhaus woes. I wrote today's IT Blogwatch on the topic, but here's my attempt to summarize here...

  1. e360, which describes itself as a legitimate direct marketer [no comment], objected to being described by Spamhaus as a spammer. It sought legal redress in an Illinois state court.
  2. Spamhaus argued that it was a U.K. organization with no business dealings in Illinois, so the court had no jurisdiction. However, before Spamhaus decided on this defense strategy it asked the court for the case to be removed from state court and moved to federal district court.
  3. Because Spamhaus then decided not appear in court, the judge decided he had no choice but to enter a default judgment in favour of e360.
  4. A further, proposed order from the court would have the spamhaus.org domain de-registered. This is potentially a huge problem for Spamhaus -- access to the Spamhaus blacklists is usually via a DNS lookup -- a query to a zone such as sbl-xbl.spamhaus.org.

For its part, Spamhaus appears nonplussed, stating that:

We think it can not actually happen, due to the effect it would have both on the Internet and on millions of users. We believe a government agency would have to step in before it happened. One U.S. government agency has begun working on a response. Before an event such as this could occur, we believe ICANN would fight the order, as ICANN understands both the technical effect as well as the political one (hint: ITU and U.S. control of the Internet).

In other words, Spamhaus is pointing to the ongoing grumbles from outside the U.S. about the continued control over Internet policymaking by the U.S. government. If Spamhaus were to "go dark" it may catalyze a new, strengthened effort to wrest control of the Internet from the U.S.

This proposed action may seriously reduce the effectiveness of our spam filters. In the meantime, what can you do to guard against the problem?

If your spam filter uses either of the Spamhaus DNS blacklists, you may be able to change the zone it uses to one that isn't under U.S. control. For example, look in your filter's configuration and change sbl-xbl.spamhaus.org to sbl-xbl.spamhaus.org.uk (note that Spamhaus has not yet confirmed that this is supported).

Alternatively, as suggested by Slashdot's The Blue Meanie, you may be able to modify the way you resolve DNS queries. In UNIX-like operating systems, you might add something like this to /etc/named.conf:

zone "spamhaus.org" in {
type forward;
forwarders {216.168.28.44; 204.69.234.1; 204.74.101.1; 204.152.184.186; };
};

Friday, 6 October 2006

Lyris or Lie-ris? Suspect Spam Stats. for False Positives

I see Lyris claims that Gmail's spam filters cause 3 percent false positives and they used to cause 44 percent earlier this year. What rubbish. And how sad that a major IT news outlet regurgitated them so uncritically.

There's no way that a real Gmail user is seeing that kind of FP percentage, no matter how they legitimately measure it (and there are several ways used, depending on whether you'd prefer to publish a tiny number or a big, scary number).

My estimate of Gmail's FP performance is about 0.01 to 0.02 percent. That's based on roughly one per week, and measured as a proportion of total email hitting the spam filter.

Reading between the lines of Lyris's report, they're only measuring as proportion of inbound marketing email, which might explain why the headline figures are so high.

Frankly, these crazy numbers cast doubt on the rest of the statistics presented in this report. Lyris clearly has an agenda here -- to instill FUD in the minds of direct marketers so that they'll sign up to Lyris's services. That's nice...

Sadly, ZD were taken in by these shenanigans and presented the figures as an "IT Fact"

Thursday, 5 October 2006

Vista Software Protection Platform disables Windows Defender

Let's see if I have this straight. In its ongoing effort to thwart pirates, Microsoft is going to prevent its anti-malware bits from working on a PC running pirated Windows Vista? Sez Computerworld:

Customers who decline to or cannot successfully validate their copy of Vista during installation will be blocked from using certain features [including] Aero ... ReadyBoost ... and Windows Defender, which protects against viruses and spyware.
So it's fine for PCs running pirated versions of Vista to spew spam and malware into my inbox? Stupid, stupid, stupid...

Tuesday, 3 October 2006

ISPs Should Fix the Zombie Problem

Zombies are a big problem, but ISPs are in a unique position to fix the problem and should be motivated to do their part. ISPs can detect when one of its customers' PCs starts sending spam, either by outbound content control or by spotting an unusual spike in volume. ISPs may even be able to detect the earlier signs of infection, such as connection to an IRC channel used to control the bots.

When an ISP detects a zombie, it should immediately prevent that subscriber from sending email. It should make contact with affected subscribers and help them clean up their machines. If necessary, ISPs could cut off all Internet access for those subscribers, moving them into a Web "walled garden" -- this would force subscribers to see a web page alerting them to the problem and giving instructions on how to clean up their PC.

ISPs should be proactive in quickly fixing such problems. ISPs may need to modify their Terms Of Service, to contractually allow them to take these actions -- but take them they should, for the sake of their business.

If ISPs don't fix such problems, their reputation and the reputation of their customers may be damaged. The anti-spam industry has woken up to the fact that reputation is a good way to filter incoming SMTP connections, without the expense of content scanning. As this view becomes more prevalent, ISP customers won't want to be associated with an ISP that takes a cavalier attitude to their reputation and that of their customers.

Tuesday, 12 September 2006

Domain Assurance Council

The Domain Assurance Council (or DAC) is a new trade body representing organizations that certify or accreditate email sending organizations and customers of those organizations. (Examples of such organizations include Habeas and Goodmail; their customers are typically ISPs and spam control technology vendors.)

With sender "authentication" (authorization) standards such as SPF and DKIM becoming more popular, there's a need for a standard way for a trusted authority to vouch for a domain name. DAC plans to help the industry create a standard way for organizations to "vouch" for a sending domain. They will do that by publishing reputation or accreditation data about a domain name in a standard form. The standard will be known as Vouch By Reference (VBR).

For example, a receiving mail system may be able to use SPF or DKIM to verify that an incoming message was sent by example.com, but it currently has no standard way of deciding if it wants to receive email from that company. Using VBR, a receiving system would be able to look up the domain and decide if it wishes to receive the message.

VBR could also allow smaller, more specialist organizations to vouch for organizations in their own vertical industry or niche (e.g. the pharmacalogical industry). The theory is that specialist authorities will know their industry better; if a sender goes bad, a specialist authority might discover this more quickly than a generalist.

VBR means that there should be no need for proprietary methods, such as Goodmail's. VBR will create a market for organization who vouch for domains; allowing its members to compete with minimum "friction." VBR should also allow customers to switch providers -- i.e. there will be no lock-in to a proprietary provider such as Goodmail.

Current members of DAC are Goodmail, Habeas, Return Path, Trend Micro, and IronPort. DAC is run by John Levine and Paul Hoffman. Paul has plenty of experience running this sort of group, having previously run the Internet Mail Consortium amongst others.