An updated IETF Internet Draft has been published for MTA Authentication Records in DNS, representing one of several current proposals aimed at design of mechanisms to reduce spoofing of email headers and delivery of (virus-bearing) spam.

The MTA Authentication Records in DNS draft borrows heavily from earlier proposals that involve use of a DNS record to check the legitimacy of an email address; it also incorporates ideas proposed by many members of the IETF MARID (MTA Authorization Records in DNS) Working Group. Other IETF draft proposals include: Sender Policy Framework (SPF): A Convention to Describe Hosts Authorized to Send SMTP Traffic; Caller ID for E-mail; The RMX DNS RR and Method for Lightweight SMTP Sender Authorization.

The MTA Authentication Records in DNS Internet Draft describes mechanisms by which a domain owner can publish its set of outgoing Mail Transfer Agents (MTAs), and mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant."

As with other current proposals, this IETF Internet Draft uses XML in its solution. Given an email message and an IP address from which it has been (or will be) received, the decision model tests whether the SMTP client at the host address authorized to send that email message. Part of the authentication process involves finding the E-mail Policy Document for the purported responsible domain; this E-Mail Policy Document contains a description of a client authorization function with four arguments (the local-part of an email address; a domain name called the "original domain"; a domain name called the "current domain"; an IP address, either IPv4 or IPv6.

An E-mail Policy Document "is modeled by an XML infoset that contains, among other things, a definition of the client authorization function; this function can be used to determine whether a domain owner is willing to take responsibility for e-mail that is sent by a particular SMTP client." The draft specification describes those parts of the XML infoset that define the mail acceptance function, provides a description of the macro expansion performed on the character data in some of the elements, and presents the algorithm by which the XML infoset may be obtained. Appendix B provides an XML Schema for 'urn:ietf:params:xml:schema:marid-1'.

This IETF proposal recognizes that "a huge majority of the unwanted email contains headers that lie about the origin of the mail; this is true of most spam and substantially all of the virus email that is sent. The document describes a mechanism such that receiving MTAs, MDAs and/or MUAs can recognize mail in this category and take appropriate action."

Bibliographic Information

• MTA Authentication Records in DNS. By Jim Lyon (Microsoft Corporation, Redmond, WA, USA) and Meng Weng Wong (pobox.com, Singapore). IETF MARID Working Group, Internet Draft. Reference: 'draft-ietf-marid-core-00.txt'. May 2004, expires November 2004. 24 pages. Appendix B presents the XML Schema for 'urn:ietf:params:xml:schema:marid-1'. IETF source: http://www.ietf.org/internet-drafts/incoming/fixed/draft-ietf-marid-core-01.txt.

  Abstract: "Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means the address is used without the permission of the domain owner. This document describes mechanisms by which a domain owner can publish its set of outgoing MTAs, and mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant..."

• Sender Policy Framework (SPF): A Convention to Describe Hosts Authorized to Send SMTP Traffic. By Meng Weng Wong (pobox.com, Singapore) and Mark Lentczner (Mountain View, CA, USA). IETF Internet Draft. Category: Experimental. 40 pages. IETF source: http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt.

  Abstract: "Email address forgery is a problem on the Internet today. Domain owners want to control the use of their names in email, but are helpless because they lack the means. This document introduces a language for domains to make email-related declarations in DNS. It defines in detail one possible sender authentication scheme for domains to describe the hosts from which they send mail. SMTP receivers can use this scheme to detect sender forgery..."

• Caller ID for E-mail. By Robert Atkinson (Microsoft Corporation). IETF Internet Draft. Category: Experimental. May 2004, expires November 2004. Reference: 'draft-atkinson-callerid-00.txt'. 38 pages. IETF source: http://www.ietf.org/internet-drafts/draft-atkinson-callerid-00.txt. Note the patent/license declaration.

  Abstract: "When e-mail is handed off today from one organization to another, as a rule no authentication of the sender of the e-mail or the computers delivering it on the sender's behalf takes place. There are some simple steps which can be taken to significantly alleviate this problem, steps which mimic within the e-mail infrastructure the caller ID mechanism found in today's telephone system. This proposal specifies that in addition to today's practice of publishing in DNS the addresses of their incoming mail servers, administrators of domains also publish the addresses of their outgoing mail servers, the addresses of the computers from which mail legitimately originating from that domain will be sent. This information will then be used in enhancements to software that receives incoming mail to verify that computers handing off a message to them in fact are authorized to do so by the legitimate administrator of the domain from which the message is purported to have been sent..." Additional information in the references.

• The RMX DNS RR and Method for Lightweight SMTP Sender Authorization. Reference: IETF Internet Draft, 'draft-danisch-dns-rr-smtp-04.txt'. Category: Experimental. May 2004, expires November 1, 2004. 44 pages. IETF source: http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-04.txt.

  Abstract: "This memo introduces a new authorization scheme for SMTP e-mail transport. It is designed to be a simple and robust protection against e-mail fraud, spam, and worms. It is based solely on organisational security mechanisms and does not require but still allow use of cryptography. This memo also focuses on security and privacy problems and requirements in context of spam defense. This document is part of the LMAP work of the Anti-Spam Research Group (ASRG) of the IRTF..."

• SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message. By Eric Allman (Sendmail, Inc) and Harry Katz (Microsoft Corporation). IETF MARID Working Group, Internet Draft. Reference: 'draft-ietf-marid-submitter-00.txt'. May 2004, expires November 2004. http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-00.txt.

  Abstract: "This memo defines an extension to the Simple Mail Transfer Protocol SMTP) service, which allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e- mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain..."

• Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys). By Mark Delany (Yahoo! Inc). IETF Internet Draft. Reference: 'draft-delany-domainkeys-base-00.txt'. May 2004, expires November 2004. IETF source: http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt.

  Abstract: "'DomainKeys' creates a domain-level authentication framework for email by using public-key technology and the DNS to prove the provenance and contents of an email. This document defines the base framework of digitally signing email on a per-domain basis. Subsequent documents leverage this base framework to prove and validate email delivery paths as well as extend signing to facilitate per-user authentication. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of 'spam' and 'phishing'. While this document presents technical details, it is not yet intended as a definitive or final specification, rather, the intent is to define a framework and sufficient technical detail to promote experimental deployment with a view to evolving into a comprehensive authentication standard for email..."

• Lightweight MTA Authentication Protocol (LMAP) Discussion and Applicability Statement. By Alan DeKok (IDT Canada, Inc), et al. IETF Internet Draft. Anti-Spam Research Group. April 22, 2004, expires October 22, 2004. Reference: 'draft-irtf-asrg-lmap-discussion-01'. 24 pages.

  Abstract: "Lightweight MTA Authentication Protocol (LMAP) is the general term for a family of proposed protocols to help address the spam problem by permitting domains to publish the set of SMTP clients which may use their name in the EHLO/HELO and MAIL FROM fields. SMTP servers can use this information to determine if a client is consensually using a domains name. This document discusses the applicability, and the costs and benefits of wide-spread deployment of the protocol family..."

About the IRTF Anti-Spam Research Group (ASRG)

"The Anti-Spam Research Group (ASRG) investigates tools and techniques to mitigate the effects of spam. The focus of the ASRG is on technology solutions, although it may consider tools and techniques to aid the implementation of legal and other non-technical anti-spam measures. It also provides input for standardization efforts within the IETF...

ASRG is an Internet Research Task Force (IRTF) Research Group. The IRTF focuses on longer term research issues related to the Internet while the parallel organization, the Internet Engineering Task Force (IETF), focuses on the shorter term issues of engineering and standards making.

From the ASRG Charter:

Problematic e-mail, informally called spam, has increased on the Internet markedly in recent years, to a point where it threatens to make e-mail unusable. The Anti-Spam Research Group (ASRG) investigates tools and techniques to mitigate the sending and effects of spam. Its focus is on approaches that can be defined, deployed and used in the near term, by addressing underlying characteristics of spam.

Work areas include new or improved anti-spam tools and techniques, administrative tools and techniques, evaluation frameworks and measurement, and approaches that involve changes to the existing applications and protocols. As work areas are defined, the chairs will convene subgroups to work on them.

Anti-spam tools and techniques include those to prevent spam from being sent, to prevent spam from being received, to distinguish spam from legitimate mail, to facilitate management responses to spam activity, and to ensure that legitimate mail is delivered in the presence of other anti-spam measures.

Administrative tools and techniques include those to share information among server and network operators about filters and other anti-spam tools, those to help network managers identify and deal with sources of spam on their networks, and codification of best current practices in spam management.

Evaluation frameworks and measurement determine how well a tool or technique accomplishes its stated goal, and the costs of the tool or technique to both those who deploy it and others who may be affected by it. It may also be useful to create taxonomies of existing techniques to predict the effectiveness of new or modified techniques.

One function of the ASRG is to look at well-specified problems that can be addressed by technical solutions. When formulated, with development of prototypes of the associated technology, these problem statements can then serve as a starting point for standardization efforts within the IETF. ASRG will choose topics likely to lead to usable results, and to avoid those that duplicate other efforts or that have proven unproductive in the past.

ASRG will, insofar as possible, coordinate with industry groups to develop tools and techniques that both are technically sound and have sufficient industry interest to be widely deployed. Although the group's goals are technical, it may consider tools and techniques to aid the implementation of legal and other non-technical anti-spam measures.

About the IETF MARID Working Group

On April 8, 2004 the IESG announced the approval of the MARID WG, chartered to continue work on the designated sender proposals discussed in the ASRG. The IETF MTA Authorization Records in DNS (MARID) Working Group was chartered to "develop a DNS-based mechanism for storing and distributing information associated with that authorization. The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks. This will help combat a certain class of domain forgery common in spam. The solution chosen, however, should be generally useful for others which might check this authorization data...

It would be useful for those maintaining domains and networks to be able to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks.

This working group [was] chartered after extensive discussion of the issues in the IRTF's Anti-spam Research Group, and it is presumed that all active participants will be familiar with the documents produced there which describe the problem. It is not, however, an extension of that research group; it has no general writ to study spam or to produce specifications on the topic. It will not consider anti-spam abatement measures outside of the area of MTA authorization.

Because individual messages may be associated with multiple domains (among them the domains present in the RFC2822 From, RFC2822 Sender, the SMTP Mail-From, and the SMTP EHLO), the first task of the working group will be to establish which of these identities should be associated with MTA authorization. Once this decision has been reached, it will limit the scope of further activity in this working group, and the chairs will rule out of order discussion related to schemes which use other identities as the basis of authorization.

The groups Technical Advisors will help ensure that the semantics of proposals originating within this group are consonant with DNS standards and syntax, and they will be available for early cross-review to ensure that this work proceeds at an appropriate pace.

Upon chartering of this working group, the IESG intends to request that the IRTF Chair and the Chairs of the IRTF's Anti-Spam Research Group seek publication of the listed input documents as Experimental RFCs, so that they are available on an archival basis. The IESG also intends to request that the RFC editor insert a note into each document informing the reader that the IETF's MARID working group has taken on the task of producing a standard in this area..." [from the Charter]