Thursday, May 8, 2008

Help fight spam - configure SenderID

Recently there has been a flood of NDR spam that has been hitting organisations that has been - frankly - a pain in the butt for them.  The way this type of spam attack works is simple.  The bad guy generates anywhere from a few hundred to a few thousand bogus emails advertising pills, watches or whatever they are selling.  They send these to bogus users at real organisations, but they create the messages with a valid sender address.  It is the sender address that is the real target of the spam attack. 

On receiving the email the receiving server looks up the recipient address and finds that it does not exist.  No one here by that name...  Most mail servers are configured to "bounce" the email by way of a special kind of email called a Non-Delivery Report (NDR).  This is then sent back to spoofed sender with the spam message as an attachment.  Because the NDR is coming from a real mail server and a valid address it will snake past most spam filtering software and real time blacklist checks, thereby delivering the content as an attachment to the target.

There is a fairly simple way to mitigate the risk of this kind of attack.  It is free to protect your own namespace and it only takes minutes.  If you are running Exchange 2003 SP2 or later you can do even more to prevent your mail server being used as the bounce server.  The answer is called SenderID and it is part of the Intelligent Message Filter installed with Exchange 2003 SP2.

From the Microsoft SenderID website:

The Sender ID framework, developed jointly by Microsoft and industry partners, addresses a key part of the spam problem: the difficulty of verifying a sender's identity.

To put it simply an email server that supports the SenderID framework queries a special DNS record to validate that the computer submitting an email is allowed to send for that domain.

The Microsoft site also includes this overview:

  1. A sender or user sends an e-mail message from an e-mail client or Web interface. No interaction or changes to the sender's client or Mail Transfer Agent (MTA) are required.
  2. The recipient's inbound e-mail server receives the e-mail message. The server uses SIDF and calls the Purported Responsible Domain's (PRA) DNS for the SPF record.
  3. The receiving MTA determines whether the outbound e-mail server's IP address matches the IP addresses that are authorized to send e-mail for the domain.
  4. For most domains and IPs, sender reputation data is applied to the SIDF verdict check.
  5. Based on the SPF record syntax, the pass or fail verdict, the reputation data, and the content filtering score, the receiving MTA delivers the e-mail message to the inbox, a junk or bulk folder, or a quarantine folder. If an e-mail fails, the receiving network may block, delete, or junk the e-mail.

So as you can possibly figure out at this point there are two things you can do in your organisation that would help.

  1. Create a Sender Policy Framework (SPF) DNS record that specifies your permitted mail servers.  This will help protect your namespace as any server that supports SenderID will check this record.
  2. Enable SenderID checking on your inbound mail server.

In order to create the SPF record, Microsoft provide an online wizard to help you generate the text that you need to put into a TXT record in DNS to make your own SPF.

To find out more about configuring SenderID on Exchange 2003 SP2 or later - refer to the Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide.

1 comment:

Ken said...

I've seen this sort of spam, but I can't understand why the spammers do it...

It seems to me there has to be a way for them to make money or they wouldn't waste their time... do you have any insights?