Close
  • Latest News
  • Artificial Intelligence
  • Big Data and Analytics
  • Cloud
  • Networking
  • Cybersecurity
  • Applications
  • IT Management
  • Storage
  • Sponsored
  • Mobile
  • Small Business
  • Development
  • Database
  • Servers
  • Android
  • Apple
  • Innovation
  • Blogs
  • PC Hardware
  • Reviews
  • Search Engines
  • Virtualization
Read Down
Sign in
Close
Welcome!Log into your account
Forgot your password?
Read Down
Password recovery
Recover your password
Close
Search
Logo
Logo
  • Latest News
  • Artificial Intelligence
  • Big Data and Analytics
  • Cloud
  • Networking
  • Cybersecurity
  • Applications
  • IT Management
  • Storage
  • Sponsored
  • Mobile
  • Small Business
  • Development
  • Database
  • Servers
  • Android
  • Apple
  • Innovation
  • Blogs
  • PC Hardware
  • Reviews
  • Search Engines
  • Virtualization
More
    Home Applications
    • Applications
    • Cybersecurity

    Who Will Win the SMTP Authentication Wars?

    By
    Larry Seltzer
    -
    March 2, 2004
    Share
    Facebook
    Twitter
    Linkedin

      Probably the single biggest news out of last weeks RSA conference was Microsofts announcement of its Caller ID for E-Mail standard. Caller ID may be the third of the three major proposals that have been announced, but now that Microsoft has put its cards on the table, a great experiment will begin. Over the next year or so, the big players in e-mail—ISPs, software vendors, major corporate users and the government—will see which of them works best.

      The three major proposals are SPF, Caller ID and Yahoos Domain Keys. SPF is actually up and running, with (as of Feb. 27) 7,957 domains registered as implementing it (although a large number of those appear to be parked, inactive domains). Caller ID is starting to roll out as Microsoft sets up the Hotmail servers to support it for outbound mail. Hotmail will begin checking inbound mail for Caller ID this summer, while other major companies, including Amazon.com and Brightmail, have agreed to test it too. Domain Keys, to be honest, hasnt even been officially announced, although Yahoo has conducted private briefings all over the place and Sendmail, the famous mail server company, has announced it is working on support for it.

      This isnt like three brands of bleach, where youve got the same chemicals in all three bottles. In fact, the more you look at these standards, the more different they look. I had been fearful that having three major standards competing would be discouraging to the market, since explaining even one of them isnt easy. And consider that the three major mail providers in the United States—AOL, Yahoo! and Microsoft—are implementing the three different standards. I think, however, that the three, or at least two of them, could complement each other. The ideal solution may be all three, or some later standard that combines the features of two or three.

      I also think that the vendors involved in these standards arent necessarily going to be hardcore proprietary about their proposals. AOL, which has implemented SPF for outside users to confirm AOLs mail servers (inbound AOL mail doesnt check SPF though), tells me they view this implementation as an experiment. They are not committed to SPF. But the dual problems of spam and e-mail worms had gotten so bad, and SPF was the most mature of authentication standards, that they moved on to the test phase. If some other standard, or combination of standards, proves more effective, AOL wont have a problem implementing it.

      Next page: Vendor Attitudes

      Vendor Attitudes

      Meng Wong, the chief designer of the SPF spec, recently posted part of his discussions with Microsoft prior to Microsoft deciding to go it alone with Caller ID. The discussion basically deals with why they chose to use XML for their encoding as opposed to a more terse custom format like SPFs. From this and other sources Im sure Microsoft seriously considered all the possibilities before coming out with Caller ID. If you want to assume Microsoft is stupid, go right ahead (Meng Wong believes emphatically that they are not stupid), but I think if the next few months show that SPF and/or Domain Keys are better at authentication, Microsoft will either modify their own spec or buy into the others. Theyre not selling SMTP authentication, theyre selling products and services that are made better by SMTP authentication, and it behooves them to use the best method available.

      At first glance, Caller ID and SPF have a lot in common, but theres an important and fundamental difference between them. Nothing to do with XML encoding; thats an interesting argument, but not all that important. The real difference is that SPF checks only the SMTP envelope address, whereas Caller ID reads the actual message in order to examine the headers.

      The envelope is a prefix of sorts to an SMTP mail message. It just gives the address of who the message is from (the SMTP “MAIL FROM:” command) and who it is to (the “RCPT TO:” command). These are not the same addresses that the user sees in the From: and To: lines, but they do govern the address to which the mail server sends a “bounce” message in case the send fails.

      One might ask: Dont spammers forge both the envelope sender and the From: address in the headers? They almost certainly do. But a phishing attacker could use a legitimate envelope address and false headers could slip through SPF. This was the main motivation for Microsoft going beyond SPFs envelope examination to full header analysis.

      /zimages/5/28571.gif

      Its not something to do capriciously. All else being equal, SPF would be desirable because it should perform better. All it needs to check is the envelope, and it can reject messages without having to receive any of the headers or data. Caller ID and Domain Keys need to read it all.

      But then Caller ID has the job of determining from the headers what they call the purported responsible address. I wont explain the algorithm for it here; see the spec itself, section 3.2 – Mapping a Message to a Purported Responsible Domain. Ive been assured by people who ought to know that this algorithm should work well, and by others who also ought to know that its not clear that it will. For the moment, Im confused. It looks to me like it certainly could work, but Ive been so suspicious for years of the truth of anything in message headers that I wonder if Caller ID can trust what it sees.

      Its possible Microsoft has other motivations for digging into message headers, especially when you consider the policy framework they are building to manage this data. Perhaps there are more opportunities to sell development and management tools with Caller ID than with the alternative approaches. Clearly you would want the opportunity to do what Caller ID does if you could be sure it was reliable. But if it doesnt work well, well soon find out, since both spammers and customers will certainly beat on it as hard as they can over the next few months.

      Next page: I Like Domain Keys

      I Like Domain Keys

      After reading all three, Im inclined to like Yahoos Domain Keys the best. It does have its downsides; its the most heavyweight for one, adding a fair processing load to outbound mail serving. And then theres the fact that not only has the spec not been made public, but there isnt even a Yahoo press release about it. Certainly its not clear that Domain Keys is a practical solution yet, but if it could be made to work it would be a leap straight into the next generation, without as many of the problems that IP-based solutions create, such as breaking mail forwarding. Domain Keys shouldnt interfere with mail forwarding, and in fact it supports multiple levels of signed messages, so that even if I remail spam to a third party and I authenticate as the sender, the recipient can confirm that the original sender was a spammer. Neat.

      And the validity of the signatures and keys in the Domain Keys scheme should be almost beyond reproach. Its not going to be worth the work involved in brute-forcing your way around the cryptography, and even if the keys were compromised it would be a quick matter to regenerate new ones, leaving only the DNS TTL as a variable in recovery. Because DNS is used as the public key repository, theres no need for complicated and expensive certificate authorities. Anyone can generate their own keys using a variety of free tools.

      The signature approach takes any uncertainty about the contents of headers out of consideration. Its irrelevant. The signature either matches the key for the appropriate domain or it doesnt. Theres less gray area for policy management than there is with Caller ID, which allows the administrator to handle mail with different degrees of validity in different ways. Domain Keys is black and white.

      /zimages/5/28571.gif

      So it could be that some combination of SPF and one of the alternatives could be the ideal solution. It seems to me that if envelope processing could determine that a message was illegitimate SPF could dispose of it. The ones that validated through SPF could go on to a different type of testing through Caller ID or Domain Keys. This would save a lot of bandwidth by using SPF for pre-screening, and avoid all the extra processing of Caller ID and Domain Keys unless they were necessary. And in the end, the only mail to be subjected to actual spam filtering would likely be genuine. It could change the nature of filtering software a great deal when spam is a rare thing, but thats another column.

      In the meantime, the disaster I feared, that of having three important authentication standards in operation, doesnt seem all that horrible anymore. My hope is that mail server vendors will offer support for all of the standards. Were entering a period of experimentation to find out what works best. But it is the case that everyone will have to support all the standards that are left standing when its all over. Otherwise, you wont be able to send mail to their users and receive mail from them. Kind of stupid, since there is a certain level of redundancy, but as long as nobodys a jerk about the intellectual property rights, theres no reason why all of them cant coexist.

      If you asked me six months ago how I thought the spam and worm problems would work out, I would confess to being an avowed pessimist. Spam and worms were taking over; only a fundamental change in the structure of Internet e-mail could stop them, and we all knew that wouldnt happen. Good thing I was wrong; it looks like the only question is what changes will happen.

      Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Be sure to check out eWEEK.coms Security Center at http://security.eweek.com for the latest security news, views and analysis.

      Be sure to add Our eWEEK.com Security news feed to your RSS newsreader:
      /zimages/5/19420.gifhttp://rssnewsapps.ziffdavis.com/eweeksecurity.xml

      More from Larry Seltzer

      Larry Seltzer
      Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
      Get the Free Newsletter!
      Subscribe to Daily Tech Insider for top news, trends & analysis
      This email address is invalid.
      Get the Free Newsletter!
      Subscribe to Daily Tech Insider for top news, trends & analysis
      This email address is invalid.

      MOST POPULAR ARTICLES

      Latest News

      Zeus Kerravala on Networking: Multicloud, 5G, and...

      James Maguire - December 16, 2022 0
      I spoke with Zeus Kerravala, industry analyst at ZK Research, about the rapid changes in enterprise networking, as tech advances and digital transformation prompt...
      Read more
      Applications

      Datadog President Amit Agarwal on Trends in...

      James Maguire - November 11, 2022 0
      I spoke with Amit Agarwal, President of Datadog, about infrastructure observability, from current trends to key challenges to the future of this rapidly growing...
      Read more
      Cloud

      IGEL CEO Jed Ayres on Edge and...

      James Maguire - June 14, 2022 0
      I spoke with Jed Ayres, CEO of IGEL, about the endpoint sector, and an open source OS for the cloud; we also spoke about...
      Read more
      IT Management

      Intuit’s Nhung Ho on AI for the...

      James Maguire - May 13, 2022 0
      I spoke with Nhung Ho, Vice President of AI at Intuit, about adoption of AI in the small and medium-sized business market, and how...
      Read more
      Applications

      Kyndryl’s Nicolas Sekkaki on Handling AI and...

      James Maguire - November 9, 2022 0
      I spoke with Nicolas Sekkaki, Group Practice Leader for Applications, Data and AI at Kyndryl, about how companies can boost both their AI and...
      Read more
      Logo

      eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site’s focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

      Facebook
      Linkedin
      RSS
      Twitter
      Youtube

      Advertisers

      Advertise with TechnologyAdvice on eWeek and our other IT-focused platforms.

      Advertise with Us

      Menu

      • About eWeek
      • Subscribe to our Newsletter
      • Latest News

      Our Brands

      • Privacy Policy
      • Terms
      • About
      • Contact
      • Advertise
      • Sitemap
      • California – Do Not Sell My Information

      Property of TechnologyAdvice.
      © 2022 TechnologyAdvice. All Rights Reserved

      Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.

      ×