MTA Authorization Records in DNS (marid)

Last Modified: 2004-06-18

Chair(s):

Marshall T. Rose <mrose+mtr.mxcomp@dbc.mtview.ca.us>
Andrew Newton <andy@hxr.us>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Technical Advisor(s):

Rob Austein <sra@hactrn.net>
Roy Arends <roy.arends@telin.nl>

Mailing Lists:

General Discussion: ietf-mxcomp@imc.org
To Subscribe: ietf-mxcomp-request@imc.org
In Body: Subscribe
Archive: http://www.imc.org/ietf-mxcomp/index.html

Description of Working Group:

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 will 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.

This working group is being 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.

Goals and Milestones:

Done    Discuss identities with which MTA authorization used for MTA authorization
Done    Interim Meeting. Focus on required semantics for MTA authorization; syntax discussions
Done    Publish one or more syntax proposals to meet required semantics
Jun 04    Final selection of syntax and document review of selected proposal
Jul 04    Working group last call
Aug 04    Submit working group document on MTA Authorization Record in DNS to PS
Aug 04    Enter FIN_WAIT

Internet-Drafts:

SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message (29773 bytes)
Sender ID: Authenticating E-Mail (23491 bytes)
Client SMTP Validation (CSV) (32131 bytes)
Client SMTP Authorization (CSA) (24029 bytes)
Domain Name Accreditation (DNA) (19161 bytes)
Behind The Curtain: An Apology for Sender ID (35191 bytes)
The SPF Record Format and Test Protocol (0 bytes)
The SPF Record Format and Sender-ID Protocol (74521 bytes)
Purported Responsible Address in E-Mail Messages (11163 bytes)
Authorizing Use of Domains in MAIL FROM (24955 bytes)

No Request For Comments