RE: [Asrg] Consent Proposal

["Peter Kay" <[e-mail]>]

OK, I'm with you on this. Can you share w/ the group what his "framework
definition" should look like so that those of us interested in assisting
can, in fact, assist?



> -----Original Message-----
> From: Yakov Shafranovich [mailto:[e-mail]] 
> Sent: Sunday, June 29, 2003 8:37 AM
> To: Peter Kay; [e-mail]
> Subject: RE: [Asrg] Consent Proposal
> 
> 
> At 09:19 PM 6/27/2003 -1000, Peter Kay wrote:
> 
> >Yakov,
> >
> >I'll summarize my response based on your points and questions below:
> >
> >What I'm talking about is that our consent framework define a very, 
> >very general set of standards such that:
> >
> >1. vendors can develop an anti-spam software module based on 
> whatever 
> >they think is a good idea.
> >
> >2. this module can be installed/plugged in/inserted/etc such that it 
> >will apply to either the MUA or MTA, depending on how it was 
>  intended.
> >
> >3. each module can interoperate with both the framework (of 
> course) and 
> >each other. This would allow modules to be installed in "series" or 
> >possibly "parallel" so that several different modules can be 
> stacked to 
> >provide a powerful anti-spam technology.
> >
> >4. The modules can be controlled by a hierarchical organization 
> >starting w/ the ISP at the highest level, then cascading to 
> the domain, 
> >then the end user.
> 
> All correct,
> 
> >If we think this is a good idea, then we can take all the different 
> >specific anti-spam approaches that have been proposed so far and go 
> >back and forth between thinking up the framework and thinking up the 
> >modifications that would be required to the existing proposed 
> >technologies.
> 
> Yes that is what I am trying to accomplish.
> 
> >The framework would primarily define the "bus" or the basic way that 
> >data would be passed from one module to another both for the MTA and 
> >MUA perspective.  The analogy here is we create a "PCI bus" 
> designed to 
> >allow end-users to control email that gets to their inbox and we let 
> >customer need and market forces to create the specific "PCI 
> Cards" that 
> >get plugged into a given email infrastructure.
> 
> I don't know if there would be a "bus" of some sort, more 
> likely a few 
> interacting protocols like CRI.
> 
> >Does this make sense or am I completely way off in 
> understanding what 
> >we're talking about when we say framework?
> >
> >Peter Kay
> >President
> >TitanKey Software Web: www.titankey.com
> >The only technology that stops spam BEFORE it's even sent
> >
> >
> > >
> > > >I think you've got the beginning of a consent-based
> > > framework. I like
> > > >it. What I'm getting out of this is:
> > > >
> > > >A. there exists a plug-in infrastructure that can run on 
> MUA or MTA 
> > > >(ISP).
> > >
> > > Plug-in is not the correct word here, we are seeking to create a 
> > > general framework with details left for specific implementations.
> > >
> > > >B. each plug-in provides for some type of policy definition,
> > > related to
> > > >the plugins purpose. This can range from filtering to CR 
> to all the 
> > > >other methods mentioned below.
> > >
> > > Each implementation/
> > >
> > > >C. each plug-in can be configured by a hierarchy. Starting
> > > w/ the ISP
> > > >(for instance), then perhaps a domain-level admin (for corporate 
> > > >applications0 and then the end-user.  We can decide on
> > > varying levels
> > > >of defaults or override capability so that for example if an ISP 
> > > >whitelists a source, the end-user may have the option to
> > > blacklist it.
> > >
> > > Are you suggesting that the various implementations 
> should be able 
> > > to interoperate? This can be done by defining interoperability 
> > > protocols like the CRI protocol for C/R systems.
> > >
> > >
> > >
> > > >To me, this reinforces what I've seen over the past few
> > > months on this
> > > >group:
> > > >
> > > >1. no one can agree what spam is. So at the end of the day, the 
> > > >user has to have the power to decide. This is in line w/ the 
> > > >charter.
> > >
> > > Agreed
> > >
> > > >2. no one technological approach "religion" (i.e. filtering,
> > > C/R, etc)
> > > >is adequate to deal with the general problem of "unwanted email".
> > >
> > > Agreed.
> > >
> > > >3. spammers will change their methods as time goes on, so the 
> > > >architecture must allow for that.
> > >
> > > Agreed
> > >
> > >
> > > >In addition, a consent-based framework allows for multiple
> > > vendors to
> > > >participate. If we can create some sort of "email bus" I
> > > think it has a
> > > >lot of potential.
> > >
> > > An email bus? Can you explain this?
> > >
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: Yakov Shafranovich [mailto:[e-mail]]
> > > > > Sent: Thursday, June 26, 2003 11:23 AM
> > > > > To: [e-mail]
> > > > > Subject: [Asrg] Consent Proposal
> > > > >
> > > > >
> > > > > I would like to provide a generic proposal for
> > > consent-based system
> > > > > as per
> > > > > charter:
> > > > >
> > > > > 1. Users and/or ISP define rules and filters to 
> filter incoming 
> > > > > email. Rules/filters are decided by end users and ISPs,
> > > and are not
> > > > > mandated.
> > > > > Every user/ISP can define its own policies ranging 
> from banning 
> > > > > all email not digitally signed to blocking HTML.
> > > > > 2. For each email user, the MUA or the ISP maintains a
> > > > > whitelist of trusted
> > > > > senders, blacklist of blocked senders and a graylist of
> > > > > unknown senders.
> > > > > Whitelisted senders go the inbox, graylisted senders go to
> > > > > the bulk folder,
> > > > > and blacklisted senders are either in the spam folder or
> > > > > erased. 3. Whitelists are not only a list of email addresses
> > > > > of trusted senders,
> > > > > but to avoid sender spoofing also have additional features
> > > > > such as digital
> > > > > signatures, certificates, passwords, tokens, etc.
> > > > > 4. Additional automatic whitelist rules are defined as such
> > > > > email from
> > > > > trusted senders (e.g. Habeas) is automatically goes to the
> > > > > inbox unless
> > > > > blacklisted, etc. C/R systems are also integrated and upon
> > > > > receiving a
> > > > > positive response automatically whitelist the sender.
> > > > > 5. Additional automatic blacklist rules are defined such as
> > > > > email coming
> > > > > from known open relays is blocked.
> > > > > 6. Whitelists, graylists and blacklists are stored hashed or
> > > > > encrypted to
> > > > > protect privacy.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > Yakov
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Asrg mailing list
> > > > > [e-mail] https://www1.ietf.org/mailman/listinfo/asrg
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Asrg mailing list
> > > >[e-mail]
> > > >https://www1.ietf.org/mailman/listinfo/asrg
> > >
> > >
> > > _______________________________________________
> > > Asrg mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/asrg
> > >
> > >
> > >
> >
> >
> >
> >_______________________________________________
> >Asrg mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/asrg
> 
> 
> _______________________________________________
> Asrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
> 
> 



_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg