Port 25 Blocking is NOT a Panacea

Increasing numbers of ISPs block the outbound SMTP port 25, requiring all outbound email to go through the ISP's official MTA, using SMTP authentication. However, ISPs that have implemented port 25 blocking shouldn't rest on their laurels.

The basic problem with port 25 blocking is the ability of botnets to subvert it. Once a PC is compromised, there's nothing to stop the virus from submitting spam to the official ISP MTA, using credentials stolen from the Windows registry or keyboard monitoring.

While port 25 blocking is useful if an ISP's only defense is outbound spam filtering, ISPs should do so much more. For example:

• Cooperating with reputation services that list IP ranges that have no business sending unauthenticated-direct-to-MX, such as Spamhaus's new PBL
• Recording the volumes of outbound port 25 traffic -- a sharp increase from the historical trend can indicate infection
• Monitoring blocked attempts to use port 25 to outside MTAs -- another indication of infection
• Disrupting botnet command and control messages
• Moving infected PCs into a "walled garden", which prevents them from sending email, surfing the Web, or using other Internet applications until the problem has been cleaned up

Why Do People Use a Backup MX?

Some organizations set up their MX records so there's an offsite backup MTA to receive mail (perhaps that should read "many organizations", I have no data). Is there still a justification for doing this?

In my simple view of the world, you simply don't need a backup MX. If your primary MX is unavailable, mail should still queue at the sending MTA for several days. The sending MTA should continue to retry periodically until your site is available again. In many ways, backup MX configurations are an anachronism -- a holdover from the days when connectivity was unreliable and some MTAs' queuing algorithms weren't great.

Backup MXs can cause problems if they don't do the same spam filtering that your primary MX does. This can cause backscatter.

If your primary MX is down for some time, a backup MX could also cause backscatter spam with "delayed" DSNs (delivery service notifications). On the other hand, not using a backup MX would usually allow the sending MTA to generate the DSN, which is a much better way to do it.

What do you think? Are there circumstances where a backup MX makes sense for you?

More About Why Cisco Bought IronPort

As I mentioned last week, Cisco bought IronPort for $830 million.

Clearly IronPort's reputation data is part of the prize for Cisco. Perhaps also, the PostX email encryption technology will possibly be useful (IronPort bought PostX last year). Perhaps some enhanced competition for Identum and Voltage? Alternatively, I fear that Cisco may let this stuff wither on the vine -- PostX customers should be concerned and watch closely.

An interesting question is what will happen (if anything) with SpamCop. IronPort deliberately ran SpamCop at arm's length as a matter of policy. It's not clear whether Cisco will maintain that policy. SpamCop is of course part of the raw data feeding into IronPort's reputation database, along with the data phoned home by the IronPort boxes.

As we saw with the BlackSpider acquisition by SurfControl, spam control companies that aggregate lots of data about spam sources are valuable, for reasons in addition to spam control. For example, if a zombie is sending spam, it's also probably a potential source of other bad stuff, such as worms and distributed denial of service attacks.

See also: my roundup of blogger reaction to this story in Friday's IT Blowatch.

Anti-Spam Market Consolidation Continues -- Cisco Buys IronPort

Today, Cisco announced that it has acquired IronPort Systems for $830m in cash and stock.

Cisco is of course well-known for its "growth by acquisition" strategy, and was notably lacking in solutions for email hygiene. It makes sense for it to buy an appliance vendor.

IronPort and Ciphertrust have been the appliance market leaders for some time (albeit challenged by the appliances launched by large, conventional software vendors such as Sophos and Symantec). Ciphertrust was of course bought by Secure Computing in 2006, thus leaving Cisco with an obvious choice.

Will we look back at 2007 as the year of spam control market consolidation? We've certainly seen some significant M&A activity in previous years, but there's still plenty of scope for your vendor to be acquired or run out of VC money.

[Edit: it's now officially $830m, not $850m as I was originally advised by IronPort]

Sender Authentication Doesn't Fix Challenge/Response

Happy new year. Sorry that the first post of January is about challenge/response (again), but surprisingly few people seem to get it.

There's this idea floating around that challenge/response filters are OK if they check SPF, SenderID, or DomainKeys -- only challenging messages that pass those checks.

Twaddle. This idea that SPF or SIDF or DKIM can tell you whether a message is forged is naive.

Firstly, implementation on the sender side is spotty. If there's no SPF record or DKIM header to check, you're back to square one.

Secondly, don't forget that most spam is sent by virus-infected computers (corralled into a botnet). There's nothing to stop virus writers from sending spam that passes an SPF/PRA/DK check at the receiving end.