Stop Spam Soon

WEBINAR:

Modernizing Authentication — What It Takes to Transform Secure Access


Date: 12/14/2017 @ 1 p.m. ET

SHARE
Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
Email  
End-users have it easy with spam. They only have to delete a few hundred messages a day. For real spam misery, try being a network or e-mail administrator with tens of thousands of spam messages clogging up your network pipes or mail server's storage.

Fortunately, an old approach, mail server authenication, has often been suggested to stop spam that may be coming back in a variety of new forms. This tack is to modify how Simple Mail Transport Protocol (SMTP) works.

Today, when a mail server gets a message from any SMTP client, it passes it on to its destination without bothering to check if the user or domain is legitimate. It's that very trick that worms like MyDoom, Gibe and Netsky use to turn infected systems into spam generating machines.

SMTP's other problem, as anyone who has ever gotten spam from what appeared to be a friend knows, is that it doesn't do a decent job of stopping spammers from spoofing, aka forging, e-mail headers. Besides making you open messages you otherwise would never have touched, it's this security hole that makes phishing messages, e-mail that appear to be from a company you deal with that asks for personal information, the bane of naove users today.

So what you can do about it? Well, some have suggested that SMTP, which was written in an era when all computers were trusted, simply be dumped and replaced. That's an interesting notion but it hardly seems likely to happen since SMTP has displaced all other would-be popular Internet level mail protocols such as X.400. For better or worse, it's an SMTP world.

There have been also been attempts to modify SMTP. For example, there is already an Internet Engineering Task Force (IETF) SMTP over SSL/TLS protocol Request for Comment (RFC) - 2821, the standards for basic Internet protocols. However, using this, and other such methods require that servers, if not users, be authenticated as being legit by some third party directory service.

Other approaches, such as RFC-2015, would use MIME Security with Pretty Good Privacy (PGP), for authentication. Until recently, these ideas got more lip service than practice, but now major companies like Microsoft, Sendmail and Yahoo are moving in the authentication direction.

Sendmail, which claims that's its self-named e-mail server is used by seven out of the Fortune top ten companies, will work on developing and distributing sender authentication technologies. That doesn't mean however, Sendmail will be creating its own authentication scheme. Instead, Sendmail appears to be looking towards Yahoo's DomainKeys and Microsoft's "Caller ID."

DomainKeys would incorporate a public-key authentication system on top of SMTP. This would work by having each message digitally "signed" with a digital signature and public key for each domain. On the other side, the receiving e-mail system uses the public key to validate the signature. Since this signature is incorporated as a new header, and SMTP can already handle such headers, mail administrators would not have to update their mail servers.

They would, however, have to use a preprocessing program, or an add-on to their existing mail server to authenticate these signatures. In addition, this system would require a trusted third party directory system, like any public key encryption system, to ensure that the keys are authenticated. All this puts more of a load on the mail server. On the other hand, the overall load on the mail server and network should be reduced since it won't be sending on much bulker spam messages. Another plus for this method is it requires absolutely nothing from end-users.

Page 2: Microsoft's Caller ID

Microsoft's Caller ID would require e-mail senders to publish their MX IP addresses in the DNS in a new format called the Caller ID for E-Mail specification. A receiving mail system would then look at a message to determine which domain was to have sent it, and then check to see if the message's IP address and MX IP address record. If they match, the message goes out. If it doesn't, the message is killed off and sent to the big bit bucket in the sky.

There is already a similar approach, Sender Policy Framework (SPF) before the IETF in an experiential RFC. SPF is an extension to SMTP. In it, Mailbox MX (Mail Exchange) Domain Name Server (DNS) records will include SPF protocol information, which is then used to see if the originating message's IP address matches the proper domain name.

SPF's authors, from mail forwarding company Pobox.com, are urging the IETF to immediately adopt SPF. One anti-spam business, CipherTrust Inc. is already using SPF in its products and other major companies like Symantec are already deploying it. SPF seems to have a groundswell of support from corporate e-mail users. Historically though, the IETF is loath to quickly make changes to its fundamental protocols.

Microsoft's Caller ID has additional challenges. While it has support from Sendmail and spam prevention companies like BrightMail, it also would include Microsoft patented technologies and a terse Microsoft Extensible Markup Language (XML) vocabulary. Although, Microsoft says it would make these use of these patents free for Caller ID users, many administrators doubt their word. Eben Moglen, law professor at Columbia Law School and General Counsel for the Free Software Foundation, also thinks that the Caller ID's license is incompatible with GPL open source mail servers.

This may prove fatal to Caller ID despite the popularity of Microsoft Exchange and its support from other customers. None of these authentication systems will work well unless an overwhelming majority of the e-mail server community adopts it.

Thus, it seems to me that, thanks to the overwhelming spam loads ISP and businesses are seeing that we will soon see an IETF blessed authentication scheme that will work with today's SMTP clients and servers. That said of the three methods, I think SPF, although it hasn't gotten the press of DomainKeys or Caller ID, is likely to be the winner since it doesn't require a public key infrastructure as Yahoo's solution does and it doesn't come with the political baggage of a Microsoft solution.

That we'll have an answer that will stop much of today's spam traffic is the good news. The bad news is that no matter what scheme wins in the end, it will be a slow process.

Thus, for now we're going to continue to need to improve our gateway anti-spam programs, and wait for the standards tussle to work itself out before our spam traffic starts to drop. Bill Gates is on record as saying that "spam will be solved" by 2006. He may be right; it just probably won't be Microsoft that solves it.

Given, of course, that spammers don't find another way to spam that doesn't rely on unauthorized SMTP clients. But, that's a problem for another day. Fixing our current number one source of spam is enough of a problem for today.

JOIN THE DISCUSSION

Loading Comments...