It's official. The IESG has approved our charter and MARID is now a
working group.
Thanks to the authors of all the input documents, participants of the
BoF at IETF 59, and those who have given feedback on the charter and
direction of this working group.
I've attached the charter. Please note that the dates listed in the
milestones are months of the year not days of the month.
-andy
MTA Authorization Records in DNS (marid)
----------------------------------------
Last Modified: 2004-3-18
Current Status: Proposed Working Group
Chairs:
Marshall Rose
<mrose+mtr(_dot_)mxcomp(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
Andrew Newton <andy(_at_)hxr(_dot_)us>
Applications Area Directors:
Ted Hardie <hardie(_at_)qualcomm(_dot_)com>
Scott Hollenbeck <sah(_at_)428cobrajet(_dot_)net>
Applications Area Advisor:
Ted Hardie <hardie(_at_)qualcomm(_dot_)com>
Technical Advisors:
Rob Austein <sra(_at_)hctrn(_dot_)net>
Mailing Lists:
General Discussion: ietf-mxcomp(_at_)imc(_dot_)org
To Subscribe: ietf-mxcomp-request(_at_)imc(_dot_)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.
Working Group Goals and Milestones:
March 04 Discuss identities with which MTA authorization
should be associated
April 04 Working Group last call on which identities will be
used for MTA authorization
May 04 Interim Meeting. Focus on required semantics for
MTA authorization; syntax discussions
May 04 Publish one or more syntax proposals to meet required
semantics
June 04 Final selection of syntax and document review of
selected proposal
July 04 Working group last call
Aug 04 Submit working group document on MTA Authorization
Record in DNS to PS.
Aug 04 Enter FIN_WAIT
Input documents:
draft-irtf-asrg-lmap-discussion
draft-stumpf-dns-mtamark
draft-brand-drip
draft-danisch-dns-rr-smtp
draft-fecyk-dmp
draft-mengwong-spf
draft-levine-fsv