[ietf-dkim] Re: The Value of Reputation

Mike Wolf mtwolfie at gmail.com
Mon Jan 2 18:25:41 PST 2006


I would be very interested in participating in a new working group or
mailing list that concentrates on reputation services that can build on the
excellent work done so far in the DKIM group.  I am also involved in another
standards effort amongst the posts of the world called the Electronic
Postmark and could see the local post office in each country potentially
playing a positive role as a reputation / accreditation service that has
some real legal teeth if we can bring these groups together.

How do we start a new WG or list that focuses on reputation?

Mike Wolf
PeerConnect, Inc.

On 1/2/06, Barry Leiba <leiba at watson.ibm.com> wrote:
>
> > Selamat tahun baru.
>
> Bonne année to you too.
>
> I agree with Dave sometimes, and disagree sometimes.  For this note,
> I agree with everything he says.  I have a few things to add (though
> as I went through it trying to add more, I realized how unnecessary
> that was).
>
> > Unless I have missed something quite basic, the proposed DKIM charter
> > and the draft DKIM specifications do not include doing work on
> reputation
> > services.
>
> Just to add one to this:
> Yes, that is correct.  And if the WG be chartered and if I be a co-chair,
> I will certainly declare any discussion of it to be out of scope.  That
> doesn't mean it can't come up here and there, as part of other
> discussions,
> but we must not focus on it, taking time from the work to hand.
>
> I, as do others, believe that some sort (or sorts) of reputation service
> will be important, and should be developed.  I see several ways to
> approach it:
> 1. Recharter this WG after its primary work is done.
> 2. Start one or more new WGs for this, beginning the chartering process
> as the DKIM work nears completion.
> 3. Work on some reputation services separately -- as I believe will happen
> in any case -- and bring some of them to the IETF after some
> experimentation.
>
> I think (1) is probably NOT the right way, but both (2) and (3) will work
> well.
>
> >> role of reputation. To say this differently, many folks seem to think
> >> you can choose a "reputation system" almost at random, and it's sure
> >> to improve your signal/noise ratio
>
> I don't think "many" people seriously think that, and hyperbole isn't
> useful
> here.  Most participants here (and I base this on what people have said)
> think
> a *well designed* system will be very useful.  That's why we should wait
> until
> we've finished some of the other discussions that pend here, so that we
> may
> take the time to design the reputation system(s) well.
>
> >>    As a practical matter, _many_ folks will prefer sorting through
> >> 100 spams to losing one good email. I see darn little "market" for
> >> anything which can't get it 99% right.
>
> Actually, I have a good bit to say about this particular item in a paper
> I'm writing for CEAS [and so here's a shameless plug for CEAS, the
> Conference
> on Email and AntiSpam, and an urging to all to consider writing papers for
> it: http://ceas.cc, and click on "2006 Call for Papers"].  The bottom line
> is that the answer varies, and whatever infrastructure we have has to have
> the flexibility to support the varying needs of different customers and
> groups.
>
> > This seems to suggest a policy requirement for all IETF work, that it
> > anticipate and document "obvious" abuses and specify the means of
> > avoiding them.
> >
> > This feels more like a bureaucratic barrier to productive work, than a
> > useful adjunct to the technical specifications work that the IETF tries
> > to perform.
>
> The suggestion seems so "obviously" reasonable that it's hard to imagine
> why we shouldn't do it.  And yet, as Dave points out, it could just pull
> the reins tight on all IETF work.
>
> Our focus has to be on making sure the specifications are clear.  We can
> (and we do) talk about some things we do NOT support and that you should
> NOT do... but, "obviously", we can't possibly cover all the "don't"s, and
> attempts to will fail, and will bring the process down with them.
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  (leiba at watson.ibm.com)
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20060102/f0c6b70f/attachment.html


More information about the ietf-dkim mailing list