RE: [Asrg] Consent Proposal

[Yakov Shafranovich <[e-mail]>]

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