0. General - Volunteers (was Re: [Asrg] Re: volunteers etc)

gep2(_at_)terabites(_dot_)com wrote:
> > We seek to understand and analyze the spam problem, before we can hope to 
> objectively evaluate proposals. 
>
> With all due respect, Yakov, this strikes me rather like the scene in the 
> broadway musical 1776 when the song says, 'We piddle, twiddle, and resolve... 
> nothing's ever solved!"
I was paraphrasing the charter:

"The purpose of the ASRG is to understand the problem and collectively 
propose and evaluate solutions to the problem."
You remark is correct that we keep on dancing around the issues without 
getting results. Thats is why I am trying at least some documents done 
so we can have a common baseline on evaluating proposals.
> I think that I proposed a quite useful discussion of approaches that would not 
> just reduce the enormity of the spam problem, but that also would make major 
> inroads into viruses and worms, too.
> My recipient-based permissions system didn't require any worldwide consensus, 
> could be implemented in as few as a SINGLE customer, and would still yield 
> IMMEDIATE benefits to that customer.  
>
> While it's certainly possible to create something far more complex and far more 
> costly, I'm not convinced that the other approaches offer value enough to 
> justify the additional complexity and cost.
> Specifically, I don't think it makes a whole lot of sense to develop some big, 
> complicated standards-based thing where spammers are (for example) encouraged to 
> write bots to hammer recipient servers to figure out just how much a given 
> recipient is going to let them get away with.  I think it makes sense to make 
> them need to ASK for greater-than-minimum permission, and to simply not be able 
> to get anything through without that, arranged in advance.
> What I'd like to see is, for starters, something freeware or shareware that a 
> SINGLE USER could implement on THEIR OWN SYSTEM, even if NOBODY ELSE IN THE 
> WORLD chose to also use it, and that would give them IMMEDIATE and DRAMATIC 
> improvement in their ability to deal with spam.
This is inline with the technical considerations document:

"    By contrast, some "edge" mechanisms provide utility to
     the first one, two or three adopters who interact with
     each other. No one else is needed for the adopters to
     gain some benefit. Each additional adopter makes the
     total system incrementally more useful. For example a
     filter can be useful to the first recipient to adopt
     it. A consent mechanism can be useful to the first two
     or three adopters, depending upon the design of the
     mechanism.
"

> Hopefully, this could then be extended to the point where it could be 
> implemented at either their ISP or domain provider, so that unwanted message 
> traffic could be truncated before quite so much bandwidth were wasted by it 
> enroute.  But that's a gilding the lily, perhaps.
> The key things that I feel such a system needs to provide are things I've 
> discussed here at length in the past but in general include:
>    1)  Ability to grant specific permissions to specific sender-destination 
> address pairs;
>    2)  Ability to deny or allow based on (at least) use of HTML-burdened 
> attachments (default: denied), other attachments (divided into at least two 
> categories:  safe (.GIF, .JPG, .TXT, etc) versus potentially malicious (.EXE, 
> .COM, .SCR, .BAS, etc etc.).  Attachments would be denied by default.
>    3)  Some kind of quarantining feature to help a user to build their initial 
> permissions list, and to help them maintain it on an ongoing basis.
>    4)  Ability to easily adjust the permissions list going forward, probably by 
> E-mailed control messages.  
>
>    5)  I've posted a suggested format for a simple, editable, text-based 
> permissions list.
> I understand fully that many here seem to think that we need to come up with 
> something a GREAT deal more complicated and that requires redesigning the whole 
> Internet E-mail system;  I disagree with that notion.
Do you think that your proposal can be put down in writing in a concrete 
document, so we can start a thread around it?
> > That is why we need to focus on the foundation of the group 
> which includes inventory of problems, requirements, evaluation model, 
> consent framework, technical considerations document, analysis, 
> bibliography, survey of solutions, identification of standardization 
> requirements, etc. All of these things either do not have volunteers or 
> are not getting very little feedback from the group members. 
>
> Part of the problem, I think, is simply that we're making the problem SO 
> complicated and SO involved that the problem is going to be solved (or at least 
> distorted out of all proportion) by bureaucrats and legislators in the 
> meanwhile.
> Honestly, I've been busy recently elsewhere and haven't been following the 
> message traffic here as assiduously as I might have.  In part that's because I'm 
> simply not seeing any convincing movement in what I consider to be a productive, 
> positive kind of direction.
What would suggest to improve this? What kind of directions should we take?

> > Without a solid foundation for the group we cannot hope to be able to evaluate 
> any proposals objectively and consider its impact on the Internet.
>
> First off, I am not even convinced that a good solution will come out of a 
> SINGLE approach to solving this problem... if nothing else, spammers have been 
> remarkably resourceful in evolving responses to most antispam defense approaches 
> that have been tried so far.  There may be a lot of advantages to trying to make 
> them respond to MANY different challenges simultaneously.
That's why a framework of many tools would probably be the answer.

> I'd like to see us come up with more than just a bunch of technical documents.  
> What I'd like to see the group come up with in the end would be some kind of 
> actual prototype (hopefully open-source or at least freeware) that would be 
> immediately, directly, useful for those wishing to evaluate these concepts on 
> their own.
> As they say, "the proof of the pudding is in the eating" and I'd like to see us 
> produce at least a simple but functional working prototype which people could 
> install on their own systems, nibble on and evaluate, and hopefully which could 
> rapidly evolve via extensions to meet new challenges as spammers change their 
> approaches.
Thats is definatly a good idea. However, many times hammering out the 
kinks in a proposal would be easier before an implementation is made. 
Thats why many times standards start off on paper first, before they are 
ever implemented. Like I mentioned, a small document outlining your 
approach and framework would be appreciated and can server as something 
around which a useful discussion can proceed.
Yakov




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg