[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
accountable
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.
Phill
> -----Original Message-----
> From: owner-ietf-mxcomp@xxxxxxxxxxxx
> [mailto:owner-ietf-mxcomp@xxxxxxxxxxxx]On Behalf Of Ted Hardie
> Sent: Monday, March 15, 2004 6:13 PM
> To: ietf-mxcomp@xxxxxxx
> 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
> 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.mxcomp@xxxxxxxxxxxxxxxx>
> Andrew Newton <andy@xxxxxx>
>
> Applications Area Directors:
>
> Ted Hardie <hardie@xxxxxxxxxxxx>
> Scott Hollenbeck <sah@xxxxxxxxxxxxxxx>
>
> Applications Area Advisor:
>
> Ted Hardie <hardie@xxxxxxxxxxxx>
>
> Mailing Lists:
>
> General Discussion: ietf-mxcomp@xxxxxxx
> To Subscribe: ietf-mxcomp-request@xxxxxxx
> 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
>