By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
There are countless phishing scams going on right now. Phishers send official looking e-mails that appear to come from legitimate companies. Often these messages ask for personal information, such as a credit card, or will offer a special deal on purchasing a product. These e-mails rip off consumers and threaten the reputations of spoofed companies. Sender ID seeks to reduce or eliminate these phishing scams by verifying that messages are sent by a legitimate domain.
How it works
The technology is primarily based on an organization's DNS infrastructure. The basic idea behind it is that the owner of a domain creates an SPF (Sender Policy Framework) record on the DNS server that contains the IP addresses of any servers authorized to send mail from that domain.
When a mail server receives an e-mail, the message contains the IP address of the sending server. The receiving mail server then uses that IP address to query the SPF record for the domain that allegedly sent the message. If the e-mail's IP matches any of the IP addresses in the SPF record, the message is assumed authentic. If the IP address does not match one of the addresses in the domain's SPF record, the e-mail is considered fraudulent; it is then discarded before it can get to the recipient's mailbox.
Issues and considerations
Although I think that Sender ID technology is a good idea, I believe that the concept is fundamentally flawed for several reasons:
Implementation involves companies simply adding records to their DNS servers (of course these records won't actually do anything unless mail recipients are using SPF-aware mail client software). But not everyone is going to create SPF records. AOL announced in September that they will not use Sender ID technology. Many open-source advocates are also refusing to use SPF technology because of disenchantment with Microsoft.
I run my business out of my home and my Internet service provider will not allow me to have a static IP address. To get around this problem, I have an ISP host my mailboxes. However, I have an Exchange server in my home that downloads mail every two minutes and places it into an Exchange mailbox. I do this so I can back up my own mail and use some of the antispam products for Exchange.
The problem is that mail coming into my organization comes into a specific IP address. But mail leaving my organization is coming from whatever address my ISP has assigned me at that moment. So even if I wanted to add an SPF record to my domain I couldn't, because I never know what address will be assigned to my outbound mail server.
Granted, I do have a weird configuration so the issues that apply to me won't necessarily apply to everyone else.
The only thing that Sender ID technology does is compare the IP address that sent a message to the IP address on file for the domain from which the message allegedly came. Unfortunately, it is simple to spoof an IP address.
If spammers want to defeat the Sender ID policy framework, they can simply send e-mail messages to the company that they intend to spoof. If the company replies to a message, spammers can extract the IP address of the company's mail server from the message. They then can spoof the company's domain name and IP address. When the recipient gets the e-mail, it would appear legitimate, because the IP address the message came from matches the IP address in the spoofed company's SPF record.
This type of scenario leads me to believe that Sender ID technology will actually make messages from spammers appear more credible.
Sender ID technology is actually more of an antifraud mechanism than an antispam mechanism. Reducing spam is simply a byproduct of reducing fraud.
I applaud Microsoft for taking measures to eliminate phishing scams. But at the same time, I believe that Sender ID technology is flawed from the start. I think the only way Sender ID technology could ever become truly useful is if there was a widely accepted way to prevent IP address spoofing.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.