RE: DRAFT charter
This makes sense to me.
It should be emphasized that the decision to exclude other technologies
in this particular group does not in any way prevent them from being
raised and persued independly in other groups.
What could foreclose these groups though would be a scheme that was
strictly limited to information to support MTA authentication by
IP address with no provision made to allow any other form of information
to ever be included.
I am a little concerned that we have the 'authorization' language in the
draft. There is a concrete distinction here as to scope.
The 'describe the configuration of a mail server' point of view would
cover information such as the IP address of the mail server and could
also extend to other information that would help the email sender
persuade the recipient that a message is not spam, in particular
accreditation information such as the accreditation information that
a Bonded Sender might provide.
Clearly we do not want to define the protocol by which such accreditations
would be verified in this group. But they are a core component of the
sender scheme that was developed at the Aspen institute roundtable and
of the Microsoft CSRI proposal. It has also been discussed at length in
the SPF group.
It should be possible to inform the recipient that an accreditation
exists. I can explain later why this is sufficient.
I would respectfully suggest that this be allowed into the scope.
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Ted
Sent: Monday, March 15, 2004 6:13 PM
Subject: DRAFT charter
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
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
This draft is on the IESG agenda for this week, for internal
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
seriously hurt our ability to get this work done.
MTA Authorization Records in DNS (MARID)
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>
General Discussion: ietf-mxcomp(_at_)imc(_dot_)org
To Subscribe: ietf-mxcomp-request(_at_)imc(_dot_)org
In Body: Subscribe
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
mechanism for storing and distributing information associated
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
there which describe the problem. This working group is not,
extension of that research group; it has no general writ to
study spam or to
produce specifications on the topic. It will not consider
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
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
and the chairs will rule out of order discussion related to
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
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
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,
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
May 04 Publish one or more syntax proposals,
as I-Ds, to meet
June 04 Final selection of syntax and document review of
July 04 Working group last call
Aug 04 Submit working group document on MTA
Record in DNS to PS.
Aug 04 Enter FIN_WAIT
|<Prev in Thread]
||[Next in Thread>
Re: Why we should choose the RFC2821 MAIL FROM/HELO identities, Jon Kyme
RE: DRAFT charter,
Hallam-Baker, Phillip <=
re: Draft Charter, Ted Hardie
RE: Draft Charter, Hallam-Baker, Phillip
Re: RE: Draft Charter, Jon Kyme
RE: RE: Draft Charter, Hallam-Baker, Phillip
- Re: Why we should choose the RFC2821 MAIL FROM/HELO identities, (continued)