Subject: RE: [Asrg] Spam Control Complexity -- scaling, adoption, diversity y and scenarios

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 22 Apr 2003 21:23:51 -0400

I do not agree, I think this group is not 'charged' to do anything but research 
into ways to mitigate spam (not stop spam) by developing methodologies 
associated with "consent-based communication" and methods for enforcement of 
policies associated with it by 'investigating the feasibility of (1) a single 
architecture that supports this and (2) a framework that allows different to be 
plugged in to provide different pieces of the solution.'

That is not a 'charge' to "stop spam" OR "stop spam by method X."

In fact I feel that is a fundamental flaw in many of these over-arching 
dialogs.  Where I see congruence however is in the desire of the group to 
provide a solution that is easily deployed and desirable to use.

I would like to stress that my reading of the charter seems to indicate that 
there is a requirement for interoperability of solutions or approaches 
envisioned in this research activity in order to achieve (2) above.  Whether 
that is network or application interoperability, single-ended or double-ended 
does not appear to be relevant at this moment as a framework has not yet been 
developed nor a single architecture.  NOTE I wrote 'at this moment' as this may 
become an issue (or not) later on.  You are both correct in pointing out 
developing these types of solutions requires innovation AND standardization to 
achieve the stated goals of the investigation activities.  So it appears there 
are two tracks for discussion.

I have stated this before - we are working without a net while we have no 
requirements.  Russell Brand and I are working on a format and presentation of 
requirements and it may be helpful to vet those with this group (or not) 
depending on how it impacts the performance of research toward a solution, 
IMHO.  In any event I hope that can clarify at a sufficiently abstracted level 
a) the problem, b) the requisite component effects  and c) the rationales for a 
solution/method.

It does not appear many do know how to approach development of such a 
framework, in a practical way, and perhaps all of the wrangling is warranted 
but I am getting the feeling that most of this is posturing among this group of 
very talented people.  Again, I have stated this before.  We know the problems 
pretty well.  Let's get on to the innovation and not continue down these 
lengthy unproductive side-tracks.

The question that began this long back and forth was I think (in high level 
terms): Will core or edge be better for developing an approach (DC).  The 
answer I think was: I don't think we can know that yet, we need more discussion 
or some better examples (PHB).  At least that is what I read into the 
conversation.

There are other issues involved in developing a framework, e.g., in the subject 
of this message; let's not forget them.

-e

On Tuesday, April 22, 2003 12:29 PM, Hallam-Baker, Phillip 
[SMTP:[email-masked]] wrote:
> Again Dave, you are putting mechanism ahead of analysis.
>
> This working group is charged with a purpose, to stop spam.
> It is not charged with stopping spam by method X.
>
> This group should not be proposing mechanisms that are worse
> than non network based mechanisms.
>
> Best practices statements have long been a feature of the
> IETF and IRTF. These have rarely considered the purely interop
> issues you are promoting.
>
> Like many others in the IETF you appear to have the idea that
> it is somehow your position to impart your learned experience
> to this group. We are well aware of the issues you have raised,
> you are not the first to have raised them.
>
> Your intervention is understood to be well intended. Understand
> that this is an area where interventions by individuals whose
> interests lie in no solution being developed are likely.
>
>
> What is needed at this stage is a FAQ which states the problems
> identified with the frequently proposed solutions. So each time
> we get another tourist comming to propose 'Sender pays' or
> 'making each person who sends me email play a little game' or
> such we do not have to go through the whole education process.
>
> I would like to propose that each proposal for a spam solution
> that already appears on the list be required to start what
> solutions it proposes to the problems identified in the FAQ.
> So that the next person to suggest sender pays is expected to
> explain what solution they propose for the infrastructure cost,
> double ended deployment problem, the freerider problem, etc.
>
>
> 		Phill
>
>
> > -----Original Message-----
> > From: Dave Crocker [mailto:[email-masked]]
> > Sent: Tuesday, April 22, 2003 11:20 AM
> > To: [email-masked]
> > Subject: Re: [Asrg] Spam Control Complexity -- scaling, adoption,
> > diversit y and scenarios
> >
> >
> > Folks,
> >
> > There seems to be some confusion about the nature of a networking
> > standard.
> >
> > Networking standards are very different from software development.
> > They specify conventions for inter-operation.  That is, they provide
> > for some type of interaction that has functions and formats that are
> > pre-speicified (ie, standardized.)
> >
> > So if this group has any interesting in doing work that leads to
> > networking standards that pertain to control of spam, it needs to
> > focus on conventions for interaction between Internet systems.  That
> > is, protocols for relevant distributed functionality, and formats for
> > relevant shared information.
> >
> > The list that Vernon produced provides some excellent examples.  By
> > contrast, simply saying that there is a component somewhere in the
> > system -- such as a filter -- does *not* provide a useful example,
> > unless there is an indication of the types of conventions that should
> > be standardized, to permit the filter to do its job.
> >
> > d/
> >
> >
> > TT> Dave Crocker wrote on 20 April 2003 02:19
> >
> > >> "doubled ended" sounds like a dandy term.  what does it mean?
> > >>
> > >> if it means "at both ends" then i would be quite
> > interested to hear how
> > >> any enhancement that involves interoperability can be
> > useful if deployed
> > >> to only one component.
> >
> > TT> Example 1:
> > TT> Email filteroing for viruses.  Implemented at receiver's
> > end. Or at
> > TT> sender's end.  Doesn't matter which.  Doesn't have to
> > implemented at both
> > TT> ends for parties who wish to interoperate.  Implement at
> > receiver's end only
> > TT> if you don't wish to interoperate with deliberate
> > transmitters of viruses.
> >
> > TT> Example 2:
> > TT> Spam filtering using a reliable BL.  Implement at
> > receiver's end.  Implement
> > TT> at sender's end if you think of sender as including ISP
> > MTA as well as
> > TT> end-user MUA.  But don't implement at receiver's end if
> > you don't want to
> > TT> interoperate with spammers.
> >
> > TT> Frankly, I think your comment is crazy. I could go on
> > listing enhancements
> > TT> that can be applied at one end or at the other end or at
> > both ends and still
> > TT> allow all required interworking until I got writer's
> > cramp, and still would
> > TT> not have listed all the ones that I have seen implemented.
> >
> > TT> Tom Thomson
> >
> >
> >
> > d/
> > --
> >  Dave Crocker <mailto:[email-masked]>
> >  Brandenburg InternetWorking <http://www.brandenburg.com>
> >  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
> >
> > _______________________________________________
> > Asrg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/asrg
> >
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg