RE: [Asrg] Consent Proposal

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).
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.
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. 

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.

2. no one technological approach "religion" (i.e. filtering, C/R, etc)
is adequate to deal with the general problem of "unwanted email".

3. spammers will change their methods as time goes on, so the
architecture must allow for that.

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.

Peter Kay
President
TitanKey Software Web: www.titankey.com
The only technology that stops spam BEFORE it's even sent

> -----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