ietf-asrg
[Top] [All Lists]

RE: [Asrg] Consent Proposal

2003-06-29 17:34:43
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



<Prev in Thread] Current Thread [Next in Thread>