Subject: RE: [Asrg] Consent Proposal

From: "Peter Kay" <[email-masked]>
Date: Thu, 26 Jun 2003 17:53:46 -1000

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:[email-masked]] 
> Sent: Thursday, June 26, 2003 11:23 AM
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
> 
> 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 26 Jun 2003 22:03:25 -0600 (MDT)

> From: "Peter Kay" <[email-masked]>

>...

Things that MTAs and MUAs can do differ radically.

> other methods mentioned below.

"Plug-in" worries me.  At best it suggests an implementation mechanism
instead of a protocol notion.  At worst it suggests an intolerable
security nightmare as is standard in commodity desktop software.

> ...

That needs to be made concrete in terms of protocols and mechanisms
so that it can be discussed by a technical group.

Vernon Schryver    [email-masked]

---

From: Barry Shein <[email-masked]>
Date: Fri, 27 Jun 2003 19:01:43 -0400

How is any of this consent/filtering related to the usual IETF purpose
such as protocol documents (RFCs, etc), network engineering, and not
just some ad hoc User Interface Engineering?

It seems to me the consent proposals (getting any attention) thus far
require no change to any existing protocols or standards, and don't
seem to imply any new protocols or standards.

Where in the stack would any of this fit and why does this group need
to be involved?

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 28 Jun 2003 13:17:49 +0100

> Where in the stack would any of this fit and why does this group need

It's seems quite likely that distributed consent mechanisms
(by which I mean that policy origination and enforcement
need not occur at the same place) will require publication of new standards
and protocols. If, that is, we're to expect inter-"vendor" applications.
Some mechanisms which support consent (eg C/R) have a strong requirement
for interoperability standards etc.

Equally, there's scope for producing useful documents covering any class of
anti-spam system which need not actually specify protocols: BCP, "Some
considerations regarding..." etc. You'll be aware that many RFCs do not
specify any protocol.

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 29 Jun 2003 01:12:06 -0400

>Where in the stack would any of this fit and why does this group need

As I mentioned before there are two models here - network abuse model which 
you are proposing and consent model which is defined in the charter. The 
network abuse model as you propose would seek to find ways to detect and 
stop spammers from using the Internet for abusive behavior (i.e. spam) It 
may also include viruses, worms, etc. as a side benefit.

Both models in my opinion are equally good. However, they call for 
different solutions and approaches. Both models will involve changing 
existing protocols (i.e. SMTP) and defining new ones (like CRI). That is 
where IETF gets involved.

The consent model specifically is not limited to the MUAs, but can be 
enforced by MTAs on ISP level as well. In order to do so a framework and 
various protocols must be worked out. I will be posting a document sometime 
later on this week laying out both models in detail.

Yakov