Subject: Re: Fwd: Re: [Asrg] Consent Proposal

From: "Jon Kyme" <[email-masked]>
Date: Tue, 01 Jul 2003 08:37:55 +0100

> In message <[email-masked]>, Yakov 
> Shafranovich <[email-masked]> writes
> 
> 
> >>>>>. Third, inter-operability with existing email is a big problem as 
> >>>>>well since no one would want to use an alternative system unless 
> >>>>>many people will switch over to it and many people will not switch 
> >>>>>others use it.
> 
> <set mode way back>
> I'm sorry Alexander Graham Bell, we can't possibly accept this new 
> fangled telephone thing you've just invented because the above quote 
> claims a catch 22 for deployment. It'll never work
> 

From the charter:
"ASRG will consider the issues of deployment for proposed solutions,
emphasizing the investigation of methods that have a realistic chance of
wide-scale deployment."

Incidentally, Bell got his patent in 1876, I have no idea how many
telephone users there were 20 years after that, but I guess many fewer than
used the telegraph. It's only in the last 50 years that the telephone has
become ubiquitous (in the "developed" world). I can remember when my mother
got the telephone installed (ca. 1966). You want to wait that long?

--

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

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 01 Jul 2003 12:29:27 +0100

> Duplicate posting received via the list and email
> 

Oh right, you're one of those. Bye.

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 27 Jun 2003 12:03:42 -0400

At 10:37 AM 6/27/2003 -0400, Bob Wyman wrote:

>Yakov Shafranovich wrote:
> > The charter goes on and on about consent, however aside
> > from Gordon's HTML blocking thread, there has been no
> > discussion of that.
>         Not true... As Selby Hatch has already pointed out, his proposal
>was focused on the consent issue. So are the various proposals that I've
>made for "license to send" and/or "single user addresses" (stuff like
>TMDA). See my first posting on 3-March -- one of the first in this
>group... Also, quite a number of the patents that I've listed at various
>times have been for "consent-based" systems of one form or another.

While it is true then specific proposals have been advanced, there has been 
no discussion of an overall consent framework that is discussed in the 
charter. Once an overall framework is discussed and in place, all the 
specific consent proposals will fit right in.

Yakov

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 27 Jun 2003 07:59:52 +0100

> 
> I'm posting this again for any who may have missed it.
> 

Please don't. A reference to the original message would be sufficient.

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 27 Jun 2003 12:29:46 -0400

At 12:55 AM 6/27/2003 -0500, [email-masked] wrote:

> > 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.
>
>I'd like to make sure that those rules can be specified differently for any
>given sender... and, for that matter, any given destination E-mail 
>address,  so
>you can give specific rights to some senders (who need those for the kind of
>things I expect to receive from them) while denying those same rights to 
>other
>senders.  Right can be extended on a strict "need to send/trust to send" 
>basis.
>
>For example, many of us have several E-mail addresses (or even catch-all
>accounts) and I might wish a given sender to be able to send something to me
>under one of my "hats" that I might not accept from them (or indeed ANYBODY
>maybe) when I'm wearing a different hat.

How the rules are defined is left to the implementators. The point is to 
create a general framework and leave most of the details of specific 
implementations.

> > 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.
>
>Again, there needs to be different privilege levels specifiable for different
>sender/destination address pairs.

Once again this is left up to the implementation.

Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 Jun 2003 14:09:34 -0400

Yakov Shafranovich wrote:
> an overall consent framework 
	Yes, I'd like to see that framework... I think there are a
number of questions that should be answered by it:

	What is the "language" of consent? When you consent, what is it
that you consent to? Or, when you withhold consent, what is it that you
withhold consent for? In simple systems, consent is binary and focused
only on senders. Either a sender may, or may not, send messages.
However, some have proposed that consent be granted in a much more
granular fashion. Thus, you should be able to consent based on a number
of attributes such as:
	0. Identity of sender
	1. Size of message
	2. Encoding of message (character sets, HTML, etc)
	3. Source IP (presence on white/blacklists)
	4. From: header matches with sending server (i.e. RMX, etc.)
	5. Presence of signatures
	6. Presence of attachments
	7. Rate of message arrival (i.e. only 3 messages per day per
sender...)
	8. Words used in message. (i.e. no message using "bad" words)
	9. Use of Multi-part MIME
	10. etc...
	The goal here should be to define the "language" of consent. To
show what can be said and perhaps understand under what circumstances it
is reasonable to say these things and what benefit can come from saying
them. Also, some attention should be paid to the issues of what can and
cannot be determined by a machine. For instance, a machine can easily
measure the size of message. A machine can also, in some cases,
determine what account was used to send a message. However, a machine
will not be able to determine the actual human who caused a message to
be sent. (not even with PKI, signatures, etc...)

	We should distinguish between consent which is implied (by
reliance on some mechanism such as RMX) or explicit -- i.e. consent that
is expressed independent of the consent management mechanism in some
form like a "license to send" or a consent token.
	Explicit statements of consent have interesting properties
especially if they are encoded in a machine readable form. For instance,
a simple expression of consent such as "I don't except mail that
contains the word 'Viagra'." can be used to parameterize the behaviour
of spam filters on the recipient's desktop as well as on upstream
processors such as the recipient's ISP's servers. One might even pass
such a statement to a potential sender. In one possible world, a sender
might have a pop-up in their editor that warns them that "Use of the
word 'Viagra' will prevent delivery of this message to one or more of
the current recipients."
	An expression of consent might also serve as a license that can
be used by the sender. For instance, if I consent to receive mail from
you, you should be able to use some kind of a token or certificate to
ensure that your messages bypass interference by any filtering
mechanisms in the channel between us.

		bob wyman

---

From: "Howard Roth" <[email-masked]>
Date: Fri, 27 Jun 2003 00:18:25 -0700

Here's an idea about validating a message before I can ever see it.  This
can be considered a consent-based concept, as it can be a parameter at the
ISP end for each mail user. It adds quite a bit of overhead to the mail
server as it requires two additional messages for each one sent.  I see it
being part of the MTA process.  I send a message to someone.  The MTA
replies to the message with a "proof of sender request, " basically a
specially formatted email message that goes back to the server that sent it
based on the return address.  The sender's MTA responds with a "confirmation
request"  if it did send the message and the message is now available for
download based on moving it from the pending directory to a user directory.
If there is no response within a certain period the message is discarded.
It's a similar concept that I use when I get a telemarketer who I may want
to pursue what they are selling.  I ask for their phone number and call then
back. Granted I don't do this very often as I usually tell them to take me
off their call list and hang up.  If this has been mentioned I apologize as
the volume of messages is quite large on this list.

In terms of Yakovs' consent based system:  I like the idea of an ISP form
that allows me to check boxes to deny HTML or non-signed messages.  And
probably enter a few basic filters like deny any message that mentions
Viagra.  Also you could determine what lists to use to deny or accept
messages.  I prefer not to filter messages on my machine, but I don't see
the typical ISP processing all these rules and filters without a substantial
increase in cost of doing business. So I think having something at both ends
makes sense in the short term.  The long term it should be an issue for the
MTA to manage based on some parameters that the user or ISP set.

I like the idea of a white list that is supported by some industry entity
like the DMA.  But I also like the way I can put my phone number in the
DMA's database and all those marketers who subscribe to their service won't
call me.

The bottom line is that consent should be easy for the general user to deal
with and understand.

Howard Roth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
Shafranovich
Sent: Thursday, June 26, 2003 2:23 PM
To: [email-masked]
Subject: [Asrg] Consent Proposal

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

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 27 Jun 2003 16:29:29 +0100

> times have been for "consent-based" systems of one form or another.

There is quite a common misaprehension (as I see it):
that systems which rely on "consent tokens" must solve the larger
problem of "consent based communication".

Clearly, consent token based systems do seek to enforce the 
recipients wish for consent based communication. 
However, generally, I can chose to consent (or not) to receive any message
(or class of messages) that I can describe, and I can hope
that there exists an agency which will enforce my expressed policy.

This is not merely an academic point. The problem has been generalised
(this is a good thing), we should be able to form a general description
of the kind of things that might offer solutions. 

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 01 Jul 2003 20:13:05 -0400

At 01:57 AM 7/2/2003 +0200, Markus Stumpf wrote:

>On Tue, Jul 01, 2003 at 10:54:46PM +0100, Danny Angus wrote:
> > We can look outside the domain of mail to find workable examples of trust,
> > PGP and SSL both make provision for the inclusion of out-of-channel trust
> > verification. I suppose in this situation it is whom you choose to inherit
> > trust from, and ultimately your trusted root trust providers.
>[..]
>
>There is no such thing as established working "trust" mechanisms in the
>Internet of today (IMHO!!) They all fail miserably as early as because of
>non existant working revocation spreading mechanisms. If I get a CERT
>from Verisign for 2 years and they revoke it after one year, who do you
>think will notice that? With their security breach some months ago
>antivirus producers added the falsly issued certs to their antigenes
>so that the end user has at least a very little chance to notice abuse.

What about a central CA issuing certificates to other CAs, controlled by 
IANA or ICANN-type of organization? There are mechanisms in place to check 
verifications of certificates in real-time, and that can be implemented as 
well.

Yakov