Close
  • Latest News
  • Artificial Intelligence
  • Video
  • 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
  • Video
  • 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 Cybersecurity
    • Cybersecurity

    MARID Proposal Presses On

    Written by

    Larry Seltzer
    Published August 2, 2004
    Share
    Facebook
    Twitter
    Linkedin

      eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

      For the past several months a standards group of the Internet Engineering Task Force named MTA Authorization Records in DNS, or MARID, has labored to form a proposed standard for SMTP authentication. That effort will move along one step this week at the 60th IETF meeting in San Diego.

      Based originally on SPF (Sender Policy Framework), an effort driven by Meng Weng Wong, co-founder and CTO of Pobox.com, it has grown in scope to include many other functions, most controversially the authentication of mail header data. The result is a set of documents defining Sender ID, which the IETF will consider for advancement in the standards process.

      /zimages/2/28571.gif Fed up with spam? Read eWEEK.coms special report

      The aim of SMTP authentication is to impose some rules on an Internet e-mail system that heretofore, when an Internet e-mail message is sent purporting to come from a particular address, there is no verification process to confirm that it did come from that address. Spammers, phishers and virus authors know this full well and use the fact to disguise the source of their messages.

      Sender ID does not pretend to be a full anti-spam solution, just a necessary part of one. Meng Wong describes a framework called Aspen under which spam is addressed by authentication, accreditation and reputation. Accreditation, according to Wong, “lets third parties vouch for senders with whom they have a prior relationship.” Reputation is more of a ratings system for senders and accreditors.

      Many companies, including Brightmail (recently purchased by Symantec), have entered the reputation service business. Sender ID directly enables authentication and accreditation and touches on reputation. It is also backward-compatible with SPF.

      SPF and almost all the many variants discussed in the working group set rules for the authorization to send mail by putting new records in the domains DNS (hence the name MARID). Understanding the specifications and the arguments between participants in the standards process often requires expert understanding of DNS jargon.

      Next page: The Microsoft bogeyman.

      The Microsoft Bogeyman

      Nothing got members of the working group more upset and caused the chair to threaten banishment more than complaints about Microsofts involvement in the drafting of the specification. Midway through the process, Microsoft and Meng Wong negotiated a convergence of SPF with Microsofts Caller ID for E-mail specification.

      While many participants objected to working with Microsoft simply on principle, the biggest objection had to do with intellectual property rights. Microsofts contributions to Sender ID are based on their Caller ID for E-mail specification, and they make unspecified patent claims on this technology. Many participants and outsiders, including free software luminary Richard Stallman, spoke up in objection to the Microsoft license for this technology, which effectively prohibits its inclusion in programs using any major open-source license.

      The IETF has no formal objection to standards based on patented technology, but there is a part of the standardization process that deals specifically with intellectual property issues. Some have observed that the Microsoft patents are probably defensive in nature (against so-called “patent trolls”) and asserted that the real threat is not the existence of patents, but a license to that patent that is too restrictive.

      /zimages/2/28571.gifFor insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzers Weblog.

      The working group has issued a request to Microsoft to clarify its position with respect to its intellectual property claims. Microsoft employees on the working group say they are working on their response, but that it needs the appropriate approvals, which have not yet been completed.

      Andy Newton, one of two chairs of the IETF MARID working group, says of the licensing issue that “it is the working group that decides if it can abide by the terms of any license for any claimed IPR within any document it wishes to standardize. In short, the working group will decide the issue.”

      Next page: DRIP, CSV, DMP, RMX, FSV, DVP, SPF, DK, C-ID

      DRIP, CSV, DMP, RMX,

      FSV, DVP, SPF, DK, C-ID”>

      SPF was not the first attempt to create a DNS-based SMTP authentication scheme. Authors of and advocates for alternative plans have been vocal in the working group, and many continue to argue vehemently for their side and against Sender-ID.

      There are two parts to an e-mail message relevant to the groups discussions, the envelope which is described by RFC 2821 and the message data, including the headers, defined by RFC 2822. SPF and many of the other proposals only check the addresses found in the envelope, whereas Caller ID and Sender ID also check the RFC 2822 contents.

      With the inclusion of Caller ID, Sender ID offers a variety of authentication and related functions to the site administrator. The major ISPs, such as Microsoft, place great value on authentication of the RFC 2822 data in order to fight “phishing” attacks.

      Because the domain presented in the envelope is not the one the user sees when reading an e-mail message, RFC 2821 schemes dont prevent phishing. A message could pass muster with SPF Classic as being sent from spammer-throwaway9942.com while having a displayed From: address of [email protected]. Sender ID determines the PRA (Purported Responsible Address), which is the address responsible for sending the message. This isnt necessarily the From: address. In the case of mailing lists, for example, another server could be responsible, and Sender ID defines a protocol for determining the correct one. The PRA algorithm is itself the subject of controversy, and many contend it cannot be accurate in all cases.

      One of the ancillary standards proposed is called SUBMITTER, an extension to RFC 2821 that provides a mechanism for proper handling of forwarded mail. Imagine a user [email protected] sends a message to [email protected]. Mail sent to [email protected] is forwarded to [email protected]. The recipient-domain.com mail server sees the message come in with MAIL FROM: [email protected], but in fact it is sent from [email protected]. By adding the submitter extension to the SMTP command (MAIL FROM:[email protected] [email protected]) the mail server can determine the PRA correctly.

      CSV (Client SMTP Validation) checks if the IP address of the sender is permitted to send for the domain. Sender ID does this, although some members of the working group think this is all it should do. This is the approach of John Leslie, who argues that we need something really lightweight, lighter than SPF.

      John Levine, author of “The Internet for Dummies,” agrees: “Personally I think even SPF Classic is too complex.” But the XML-based caller ID portions of Sender ID are what really turn Levine off. “Extensibility sounds nice in principle, but the reality is that each time you add something new, you also introduce compatibility issues with everyone else who doesnt have your new feature or who has different new features of their own. But thats not going to work in the e-mail world.” Levine is not alone in this view, but the XML-based Sender ID was moved along in no small part because of the extensibility it allows.

      SPF Classic, as its author calls the old SPF, has a certain amount of extensibility in it, but its awkward. XML was designed for extensibility. And Verisigns Phillip Hallam-Baker points out that XML development tools and libraries are ubiquitous and powerful. Levine sees XML turning grotesque; Hallam-Baker sees it as leading to elegance. The working group sided with Hallam-Baker.

      The jury may still be out on another XML concern, verbosity. Microsoft designed the Caller ID syntax to be terse for an XML vocabulary, with tags being one or two, occasionally three characters long. Detractors note the performance implications for DNS when it is asked to store large chunks of data. DNS usually stores relatively short amounts of data. Each item is limited to 512 bytes, although there are ways to extend them. Also, increasing the size of entries in DNS might require that it be queried using TCP rather than the faster UDP.

      Dave Crocker, author of RFC 822 (the standard for text messages sent, for example, in e-mail, a standard so old it was written for “ARPANET”), is concerned about the complexity of the Sender ID proposal and sees it as an invitation to new security problems, inefficiencies and miscellaneous other errors. While he sees value in validating the From: and some other header fields, he doesnt actually see spoofing as an inherent part of the spam problem, and therefore Sender ID is not a direct response to it.

      Next page: What happens now?

      What Happens Now


      ?”>

      As fast as the process has gone so far, and thats very fast by IETF standards, the process has a ways to go. According to Andy Newton, the working group will meet in San Diego to put finishing touches on the draft documents, and then a “last call” goes out to the working group.

      “Once the working group has consensus on these documents,” according to Newton, “we will send them to the IESG (Internet Engineering Steering Group) for approval. ” The IESG will then issue an IETF-wide last call. Once IESG concerns are satisfied, the documents will be given to the RFC Editor, where they will be published as a Proposed Standard. (RFC 2026 covers the IETF standardization process.)

      Its easy to notice the dissension in the working group discussions, but its not too hard to notice the support for the standard as well, at least with respect to individual parts of what is a complex standard. Levine has a point in his observation that the SMTP we have all come to know over the years is a very simple standard (after all, the “S” in SMTP is for “simple”). Sender ID makes it much more complex.

      /zimages/2/28571.gif Read all about Microsofts battle to deliver secure software in eWEEK.coms special report on

      Many have expressed skepticism that the Internet community will move quickly to adopt the new standard, but they may be pushed along sooner than they would expect. According to Meng Wong, AOL and Earthlink are already publishing SPF records and Microsoft recently committed to do so. If all the major mail providers start supporting SPF or Sender-ID and classifying mail based on them, other parties may need to join in lest their mail be relegated to a disreputable status and placed in the “Unauthenticated” folder of E-mail users.

      The leadership of the IETF and the working group may recognize the importance of this, as have the major mail server vendors, such as Sendmail, most of whom have also committed to work with the standards.

      The alternative is, at the very least, unpleasant: Spam will continue to increase as a percentage of Internet e-mail, and the only methods to stop it, filtering software, will lose the arms race.

      Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

      /zimages/2/28571.gifCheck out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis.
      Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page: http://us.i1.yimg.com/us.yimg.com/i/us/my/addtomyyahoo2.gif

      More from Larry Seltzer

      Larry Seltzer
      Larry Seltzer
      Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement— 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

      Get the Free Newsletter!

      Subscribe to Daily Tech Insider for top news, trends & analysis

      MOST POPULAR ARTICLES

      Artificial Intelligence

      9 Best AI 3D Generators You Need...

      Sam Rinko - June 25, 2024 0
      AI 3D Generators are powerful tools for many different industries. Discover the best AI 3D Generators, and learn which is best for your specific use case.
      Read more
      Cloud

      RingCentral Expands Its Collaboration Platform

      Zeus Kerravala - November 22, 2023 0
      RingCentral adds AI-enabled contact center and hybrid event products to its suite of collaboration services.
      Read more
      Artificial Intelligence

      8 Best AI Data Analytics Software &...

      Aminu Abdullahi - January 18, 2024 0
      Learn the top AI data analytics software to use. Compare AI data analytics solutions & features to make the best choice for your business.
      Read more
      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
      Video

      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
      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.
      © 2024 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.

      ×