RE: [Asrg] Consent Proposal
"Peter Kay" <peter@titankey.com> Sat, 28 June 2003 07:20 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17606 for <asrg-archive@odin.ietf.org>; Sat, 28 Jun 2003 03:20:39 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S7K9U15878 for asrg-archive@odin.ietf.org; Sat, 28 Jun 2003 03:20:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WA0G-00047y-IW for asrg-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 03:20:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17599; Sat, 28 Jun 2003 03:20:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WA0E-0001wc-00; Sat, 28 Jun 2003 03:20:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WA08-0001wZ-00; Sat, 28 Jun 2003 03:20:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WA09-00041H-6c; Sat, 28 Jun 2003 03:20:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W9zx-00040i-OZ for asrg@optimus.ietf.org; Sat, 28 Jun 2003 03:19:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17571 for <asrg@ietf.org>; Sat, 28 Jun 2003 03:19:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W9zg-0001wB-00 for asrg@ietf.org; Sat, 28 Jun 2003 03:19:32 -0400
Received: from imail.centuryc.net ([216.30.168.20] helo=isp-appsvr01.centuryc.com) by ietf-mx with esmtp (Exim 4.12) id 19W9zV-0001va-00 for asrg@ietf.org; Sat, 28 Jun 2003 03:19:21 -0400
Received: from cybercominc.com [66.91.134.126] by isp-appsvr01.centuryc.com (SMTPD32-8.00) id A19A154000F4; Fri, 27 Jun 2003 21:19:54 -1000
Received: from a66b91n134client123.hawaii.rr.com (66.91.134.123) by cybercominc-zzt with SMTP; Sat, 28 Jun 2003 07:23:56 GMT
X-Titankey-e_id: <eff98467-853b-456b-b0d9-ac822a36dfdc>
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Asrg] Consent Proposal
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <DD198B5D07F04347B7266A3F35C42B0B0FD088@io.cybercom.local>
Thread-Topic: [Asrg] Consent Proposal
thread-index: AcM83O3MLwOQaFMvRcGQumwVJIrx8wAZc6Bw
From: Peter Kay <peter@titankey.com>
To: Yakov Shafranovich <research@solidmatrix.com>, asrg@ietf.org
Content-Transfer-Encoding: quoted-printable
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Fri, 27 Jun 2003 21:19:47 -1000
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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. 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. 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. 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@solidmatrix.com] > > > Sent: Thursday, June 26, 2003 11:23 AM > > > To: asrg@ietf.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@ietf.org > > > https://www1.ietf.org/mailman/listinfo/asrg > > > > > > > > > > > > > > > > >_______________________________________________ > >Asrg mailing list > >Asrg@ietf.org > >https://www1.ietf.org/mailman/listinfo/asrg > > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg > > > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- RE: [Asrg] Consent Proposal Peter Kay
- [Asrg] Consent Proposal Mark McCarron
- Re: [Asrg] Consent Proposal Jon Kyme
- [Asrg] Trust, misunderstood? Danny Angus
- [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Jon Kyme
- Re: [Asrg] Consent Proposal Barry Shein
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Peter Kay
- Re: [Asrg] Consent Proposal Selby Hatch
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Vernon Schryver
- RE: [Asrg] Consent Proposal Peter Kay
- RE: [Asrg] Consent Proposal Peter Kay
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Peter Kay
- [Asrg] Consent Proposal gep2
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Bob Wyman
- Anticipatory whitelisting (was Re: [Asrg] Consent… Bruce Stephens
- Re: [Asrg] Consent Proposal Jon Kyme
- Re: [Asrg] Consent Proposal Jon Kyme
- Re: RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Barry Shein
- RE: [Asrg] Consent Proposal Peter Kay
- Re: [Asrg] Consent Proposal Walter Dnes
- Re: RE: [Asrg] Consent Proposal Jon Kyme
- Re: [Asrg] Consent Proposal Jon Kyme
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Fwd: Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Fwd: Re: [Asrg] Consent Proposal Yakov Shafranovich
- Fwd: Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: Fwd: Re: [Asrg] Consent Proposal Craig Cockburn
- Re: Fwd: Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: Anticipatory whitelisting (was Re: [Asrg] Con… Yakov Shafranovich
- Re: Fwd: Re: [Asrg] Consent Proposal Jon Kyme
- Re: [Asrg] Consent Proposal Danny Angus
- RE: Fwd: Re: [Asrg] Consent Proposal Jon Kyme
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Bob Wyman
- RE: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Howard Roth
- Re: RE: [Asrg] Consent Proposal Jon Kyme
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- RE: [Asrg] Consent Proposal Danny Angus
- Re: [Asrg] Consent Proposal Markus Stumpf
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Consent Proposal Danny Angus
- Re: [Asrg] Consent Proposal Markus Stumpf
- Re: [Asrg] Consent Proposal C. Wegrzyn
- Re: [Asrg] Consent Proposal Markus Stumpf
- Re: [Asrg] Consent Proposal C. Wegrzyn
- Re: [Asrg] Consent Proposal Markus Stumpf
- Re: [Asrg] Consent Proposal C. Wegrzyn
- Re: [Asrg] Consent Proposal Yakov Shafranovich
- Re: [Asrg] Trust, misunderstood? Yakov Shafranovich
- Re: [Asrg] Trust, misunderstood? C. Wegrzyn