RE: [Asrg] Consent Proposal

I will be writing up something this week and will post it to the list, sowe can start working on defining this.


At 02:32 PM 6/29/2003 -1000, Peter Kay wrote:

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:research(_at_)solidmatrix(_dot_)com]
> Sent: Sunday, June 29, 2003 8:37 AM
> To: Peter Kay; asrg(_at_)ietf(_dot_)org
> 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:research(_at_)solidmatrix(_dot_)com]
> > > > > Sent: Thursday, June 26, 2003 11:23 AM
> > > > > To: asrg(_at_)ietf(_dot_)org
> > > > > 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
> > > > > Asrg(_at_)ietf(_dot_)org https://www1.ietf.org/mailman/listinfo/asrg
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Asrg mailing list
> > > >Asrg(_at_)ietf(_dot_)org
> > > >https://www1.ietf.org/mailman/listinfo/asrg
> > >
> > >
> > > _______________________________________________
> > > Asrg mailing list
> > > Asrg(_at_)ietf(_dot_)org
> > > https://www1.ietf.org/mailman/listinfo/asrg
> > >
> > >
> > >
> >
> >
> >
> >_______________________________________________
> >Asrg mailing list
> >Asrg(_at_)ietf(_dot_)org
> >https://www1.ietf.org/mailman/listinfo/asrg
>
>
> _______________________________________________
> Asrg mailing list
> Asrg(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/asrg
>
>
>



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



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