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