[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Asrg] Spam Control Complexity -- scaling, adoption, diversit y and scenarios
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:dhc@dcrocker.net]
> Sent: Tuesday, April 22, 2003 11:20 AM
> To: asrg@ietf.org
> 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:dcrocker@brandenburg.com>
> Brandenburg InternetWorking <http://www.brandenburg.com>
> Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>
> _______________________________________________
> Asrg mailing list
> Asrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg
>
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg