E-mail address spoofing is a big problem associated with spam and viruses.  It occurs when a message appears to come from one address but has actually been sent from a different one.  You may know how frustrating these phony messages are when a user asks why an e-mail message he did not send bounced — and he doesn’t even recognize the recipient! 

Not a Cure-All . . . but a Start
Be aware, anti-spoofing efforts will not stop spam or viruses — but they will better assist in identifying spam.  There are three proposed anti-spoofing solutions cited below.  They use varying techniques to attempt to validate the source, but all center on reducing the flow of spoofed e-mail; and in most cases, they make use of infrastructure already in place, notably DNS.  The three leading solutions are: 

1. Microsoft’s Caller ID/Sender ID
2. Pobox.com’s Sender Policy Framework (SPF)
3. Yahoo’s DomainKeys

Sender ID results from a merging of Microsoft’s Caller ID and SPF.  Microsoft is working on patents around their anti-spoofing framework.  The original specification called for verification of the sender domain; however, how that was accomplished was not explicitly defined and left options open, including integration with DNS and SPF.  Unfortunately, talks broke down to merge the specifications, due to the insistence by Microsoft to maintain control and that of the IETF that Microsoft release some control of the specification.

A benefit of Sender Policy Framework (SPF) is that it’s free.  Anyone can publish an SPF record in DNS.  SPF-aware plugins exist for all the major MTAs, except Exchange.  Many anti-spam vendors are using or investigating and adopting SPF as part of their solutions, including SpamAssasin, BrightMail, IronPort and Mailfrontier.

SPF works by publishing an SPF record in DNS.  This is a DNS txt record that simply says where e-mail can come from for your domain.  An MTA receiving mail from your domain looks up your SPF record in DNS and compares it to the mail headers.  If the source of the message matches the SPF record, the message is allowed.  If the records do not match, it can be discarded or studied more carefully by anti-spam software.  The main drawback to SPF, a small one, is that it breaks mail forwarding.

DomainKeys works similarly to Sender ID and SPF but adds the benefit of confirming the message content that arrives is the same content that left the sender.  DomainKeys uses a private key to sign each outgoing message and prepend the signature to the message header.  The receiving e-mail system looks up the public key for the sender’s service in DNS and is able to confirm the message has been unchanged in transit and is from the sender it says it is from.

Drawbacks to DomainKeys include increased processing time creating the signature of the e-mail message — but having an authenticated and signed message may more than make up for that shortcoming.

What You Can Do Right Away
Confirm that your e-mail server is not an open relay.  You may have done this already, but check to be sure.  You can use the open relay check at ORDB (http://www.ordb.org/submit/) to test your e-mail server.  If you have an open relay, get it closed as soon as possible.

Make sure your official e-mail server is the only server that can send e-mail from your organization.  Apply egress filters at the firewall to stop outbound SMTP unless it is from officially recognized machines.

Publish an SPF record for your e-mail server.  There is an SPF wizard at spf.pobox.com that should be suitable for most firms.  Your ISP may be able to help with this.  You do not have to check for SPF records yet, but large ISPs like AOL can confirm you are who you say you are.

All of these solutions are in development or starting to roll out.  SPF appears to be the farthest along.  Again, none of these anti-spoofing technologies will fix your spam problem; but if we are aware of the available solutions and add them to the criteria for our future e-mail solutions, the situation will begin to improve.  Perhaps ILTA members should endorse one of these specifications.  It will be heartening to know that e-mail coming from your client is truly from your client.

An excellent source for additional information can be found at www.cert.org/tech_tips/email_spoofing.html.

About our author . . .

Nathan Smith is currently employed by McKee, Voorhees & Sease, P.L.C., an intellectual property law firm in Des Moines, Iowa.  He is a 12-year veteran of PC network administration and information technology.  He can be reached at 515.288.3667 or smith@ipmvs.com.