RE: [Asrg] Consent Proposal

[Yakov Shafranovich <[e-mail]>]

I will be writing up something this week and will post it to the list, so 
we 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:[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


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