If you've been following the news on the IETF front then you know the
BOF in Seoul was a success and concluded with the decision to form a
Working Group.
I was glad to hear of this decision. There has been significant
resistance to the designated sender concept. RISKS recently had a
discussion about SPF (a discussion which demonstrated a surprising level
of ignorance.) Some elements of the opensource MTA developer community
also dislike SPF, mostly because it breaks forwarding.
(Sendmail.com has said they will support Caller-ID, DomainKeys, and SPF;
apparently sendmail.org does not feel that way. Eric Allman still
objects to SPF's syntax, calling it baroque. Wietse Venema has come out
against SPF, and the qmail list similarly finds itself attached to the
"it breaks forwarding" argument.)
It seems to me that getting an IETF imprimatur is the best and most
convincing way to respond to these criticisms.
Subsequent to the Seoul BOF, Ted Hardie, an AD, has produced a draft WG
charter and timeline. The charter looks reasonably compatible with the
goals of the SPF project. The SPF community has invested significant
engineering effort in refining the specification and producing something
like a dozen implementations. We're on track to 10,000 registered
domains this month. My biggest concern was that the IETF WG would
discard all that effort and spend a year climbing the learning curve
just to get to where we are today. I am glad to say that the draft
charter recognizes that scenario as a danger. When the WG mailing list
is officially started, I hope the active members of the SPF list will
subscribe to it, so we can represent the experience of the SPF community
and keep up the momentum we've developed.
If you're not familiar with IETF procedure, you may wish to read
http://www.ietf.org/tao.html
I want to take this opportunity to publicly thank all the leaders of the
SPF project --- everybody who has given their time and energy to keeping
up with the mailing list, helping newbies, spreading the word,
constructing and critiquing the specification, writing tests, writing
implementations, deploying implementations, experimenting with SPF
records, developing scaffolding infrastructure, websites, documentation,
translations, wikis, and generally doing all those things that need to
be done to make a project a success. You know who you are. Thank you.
Working together, in just a few short months we have achieved something
truly extraordinary. It wouldn't have happened without you.
cheers
meng
On Mon, Mar 15, 2004 at 03:13:26PM -0800, Ted Hardie wrote:
|
| Below is a DRAFT charter; I believe it reflects the consensus of the
| meeting,
| has a reasonable description of the aim of the group, and reflects a
| strong project
| management focus, designed to help us meet the timeline we need to
| make this work relevant. The two proposed Chairs, Marshall Rose and
| Andy Newton, are both experienced and I believe they will work well
| together..
|
| This draft is on the IESG agenda for this week, for internal review;
| comments
| to the list, Chairs, me, or IESG are all appropriate. I hope, however,
| that we
| can focus on the big picture here, as spending too much time on the
| charter will
| seriously hurt our ability to get this work done.
|
| regards,
| Ted Hardie
|
|
| MTA Authorization Records in DNS (MARID)
|
| 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>
|
| 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 useful for Mail Transfer Agents (MTAs) to be able to
| confirm that peer MTAs are authorized to send mail on behalf of a
| specific domain or network. This working group will develop a DNS-based
| mechanism for storing and distributing information associated with that
| authorization. While the primary current use case for this facility is to
| combat a certain class of domain forgery in spam, the solution chosen
| should be generally usable for MTA authorization.
|
| 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. This working group 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.
|
| An individual message may be associated with multiple identities
| (specifically 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.
|
| 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 Publish one or more proposals, as I-Ds, specifying
| the
| required semantics used for MTA authorization.
|
| April 04 Working Group last call on which identities will be
| used for MTA authorization
|
| May 04 Interim Meeting to determine which semantics proposal
| to use.
|
| May 04 Publish one or more syntax proposals, as I-Ds, 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
The input documents listed above can be found at
http://asrg.kavi.com/apps/group_public/documents.php?wg_abbrev=
https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=irtf-asrg&search_rfcnumber=&search_area_acronym=&search_button=SEARCH
I prepared a summary at
http://spf.pobox.com/marid/index.html