Subject: [Asrg] 4. Survey of Solutions - Consent Model

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 03 Jul 2003 15:38:41 -0400

I wrote up an document on the consent model 
(http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html). 
This is a rough draft, so please don't eat me :) Please comment on 
everything including any items that you think I extra. I will probably be 
changing it into a Internet Draft format soon. Below is the main part of 
the document.

---snip----
4. Overview of Consent Model.

The idea for consent model within the ASRG was first proposed in 
[ASRG-CHARTER]:
"Therefore, we generalize the problem into "consent-based communication". 
This means that an individual or organization should be able to express 
consent or lack of consent for certain communication and have the 
architecture support those desires."

This model assumes that users should be able to define what kind of email 
they want to receive - this is refered to as "consent" . "Lack of consent" 
is either when no prior consent existing or the users revoked their prior 
consent. This model does not concern itself with defining what spam is  
one person's spam message may be another's freedom of speech. Thus, we only 
seek to define a framework to let users grant and deny consent, the rules 
under which this process is done is best left to the implementors and the 
users themselves.

In the consent model we have a SENDER and RECEIVER of email that 
communicate with each other. The messages between the SENDER and the 
RECEIVER are processed by MUAs and transferred by MTAs. The RECEIVER can 
express his CONSENT POLICY to his MUA and MTA, which will enforce it for 
incoming messages. This policy may be communicated to the SENDER under 
specific circumstances, usually after being triggered by an incoming email 
message from the SENDER. This purpose of this communications will be to 
inform the SENDER of lack of consent by the RECEIVER and to request a 
CONSENT TOKEN (if applicable). A CONSENT TOKEN is a piece of data exchanged 
between the RECEIVER and the SENDER, which will grant consent to the SENDER 
in accordance with the CONSENT POLICY of the RECEIVER. Examples of such 
tokens are C/R messages, hash cash tokens, e-postage, digital certificates, 
trusted sender seals (such as Habeas and BondedSender), etc. Upon recipient 
of a valid CONSENT TOKEN, the RECEIVER will grant consent to the SENDER to 
a period of time defined by the CONSENT POLICY.

A CONSENT POLICY of a specific end-user does not merely reflect his 
choices. It is also based on the CONSENT POLICY of the software being used, 
the organization to which the end user belongs, and the ISP. The software 
being used, specifically the MUA and the MTA, might support only specific 
types of consent rules which will be used in creation of the policy. 
CONSENT POLICIES from multiple users maybe combined to create a combined 
CONSENT POLICY for the entire organization or ISP. The organization or ISP 
may also impose its CONSENT POLICY on its users and subscribers.

MTAs when communicating with each other may share CONSENT POLICIES to 
facilitate communications. They may also pass CONSENT TOKENS between 
themselves in order to dynamically grant or revoke consent to the RECEIVER. 
Multiple ISPs and organizations may also shared CONSENT POLICIES in order 
to allow for interoperability between themselves. Standard CONSENT POLICIES 
may also be defined as Best Current Practices (BCP) documents.

A CONSENT POLICY specifies the rules under which email is accepted or 
revoked. To enforce these rules the MTAs and MUAs may rely on various other 
sources of data being provided either in the message body, by the SENDER or 
from third parties on the Internet.

Two aspects must be kept in mind. First of all consent systems may grant or 
revoke consent automatically based on the CONSENT POLICY. The policy does 
not define consent only, it also defines conditions for automatically 
granting and revoking consent. Additionally, machines cannot perfectly 
reproduce human wishes and the CONSENT POLICY created might not match 
exactly what the end-user wants especially considering other CONSENT 
POLICIES such as the organization's and the ISP's.

5. Taxonomy of Anti-Spam Systems Within the Consent Framework.

There are three basic types of anti spam tools within the consent 
frameworks defined in [ASRG-CHARTER]:
"Possible components of such a framework may include:
o Consent Expression Component:
This involves recipients expressing a policy that gives consent or 
non-consent for certain types of communications
o Policy Enforcement Component:
This involves subsystems within the communication system that enforce the 
policy. The overall framework may involve multiple subsystems within the 
policy enforcement component. This may involve fail-open or fail-closed 
approaches. With a fail-open approach, the system must identify messages 
that do not have consent. For example, this may include approaches that 
determine the nature of a message based on its characteristics or input 
from a collaborative filtering system. With a fail-closed approach, the 
system must identify messages that do have consent and only allow those to 
be delivered. For example, consent may be expressed by a policy, by a 
"consent token" within the message, or by some payment that essentially 
purchases consent or delivery rights.
o Source Tracking Component:
This component provides deterrence to parties that consider violating the 
policy by facilitating identification and tracking of senders that violate 
the policy. This may require non-repudiation at the original sender, the 
sender's ISP, or some other entities involved in the communication system."

5.1. Consent Expression Component.
This category includes tools that let users express their consent choices. 
The choices that the user makes are then translated into a CONSENT POLICY 
which may be restricted by the software implementation, the organization or 
the ISP. Today there is no one comprehensive plan or language to express 
consent. Examples of such tools include:

Filter definitions

Spam tools configuration files

Blacklists

Whitelists

5.2. Policy Enforcement Component.

This category includes portions of the MTAs/MUAs that enforce the CONSENT 
POLICY defined for the end user as modified by the organization and the 
ISP's CONSENT POLICIES. These tools are used while the SMTP transaction 
takes place. Today there is no one comprehensive type of tool to do that, 
instead combinations of tools are used. Examples of these tools include:

Challenge/Response Systems

Reverse DNS checks (RMX/rDNS/etc.)

Lookups in Realtime Black Lists (RBLs)

Verification of digital certificates with a CA

Checking for trusted sender seals (Habeas, etc.)

Filtering (SpamAssasin, etc.

Lookups in known spam databases (SpamNet., DCC, etc.)

Blacklisting

Greylisting

Virus scanning

5.3. Source Tracking Component.

This category includes various tools that track spam and spammers. These 
tools produce data that is used by POLICY ENFORCEMENT COMPONENTS for 
enforce policies; and by ISPs and LEAs for track down spammers. Today there 
is no single comprehensive standard for this. Example of these include:

Coordinated spam detection (DCC, SpamCop, SpamNet, Razor, etc.)

Open relay testing (MAPS, RBLs, etc.)

Detection of hacked computers (Dshield.org, etc.

6. Standardization Considerations.

In order for the consent model to operate properly, we need to define the 
following items:
1. Language for expressing consent.
2. Machine readable format for CONSENT POLICIES
3. Machine readable format for CONSENT TOKENS
4. Protocols for sharing CONSENT POLICIES
5. Protocols for sharing CONSENT TOKENS
6. Protocols for different components of the consent framework to 
communicate among themselves.
---snip--- 

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

---

From: Selby Hatch <[email-masked]>
Date: Thu, 03 Jul 2003 20:01:36 -0600

Yakov Shafranovich wrote:

> everything including any items that you think I extra. I will probably 
> be changing it into a Internet Draft format soon. Below is the main part 
> of the document.
> 
> ---snip----
> "Therefore, we generalize the problem into "consent-based 
> communication". This means that an individual or organization should be 
> able to express consent or lack of consent for certain communication and 
> have the architecture support those desires."
> 
> This model assumes that users should be able to define what kind of 
> email they want to receive - this is refered to as "consent" . "Lack of 
> consent" is either when no prior consent existing or the users revoked 
> their prior consent. This model does not concern itself with defining 
> what spam is  one person's spam message may be another's freedom of 
> speech. Thus, we only seek to define a framework to let users grant and 
> deny consent, the rules under which this process is done is best left to 
> the implementors and the users themselves.
Yes.
> incoming messages. This policy
References to this policy . . . (not the entire policy)
may be communicated to the SENDER under
> specific circumstances, usually after being triggered by an incoming 
> email message from the SENDER. This purpose of this communications will 
> be to inform the SENDER of lack of consent by the RECEIVER and to 
> request a CONSENT TOKEN (if applicable). A CONSENT TOKEN is a piece of 
> data exchanged between the RECEIVER and the SENDER, which will grant 
> consent to the SENDER in accordance with the CONSENT POLICY of the 
> RECEIVER. Examples of such tokens are C/R messages, hash cash tokens, 
> e-postage, digital certificates, trusted sender seals (such as Habeas 
> and BondedSender), etc. 
Don't forget my simple keys.
Upon recipient
receipt
of a valid CONSENT TOKEN, the
> RECEIVER will grant consent to the SENDER to a period of time defined by 
> the CONSENT POLICY.
I'm a little confuesed by the previous sentence. Do you mean that the
receiver will send a consent token to the sender and that from then
on, the receiver grant consent to the sender?

> choices. It is also based on the CONSENT POLICY of the software being 
> used, the organization to which the end user belongs, and the ISP. The 
> software being used, specifically the MUA and the MTA, might support 
> only specific types of consent rules which will be used in creation of 
> the policy. CONSENT POLICIES from multiple users maybe combined to 
> create a combined CONSENT POLICY for the entire organization or ISP. The 
> organization or ISP may also impose its CONSENT POLICY on its users and 
> subscribers.
For individually owned mail boxes, the consent policy should be unique
and specific to the mailbox owner.
> themselves in order to dynamically grant or revoke consent to the 
> RECEIVER. Multiple ISPs and organizations may also shared CONSENT 
> POLICIES in order to allow for interoperability between themselves. 
> Standard CONSENT POLICIES may also be defined as Best Current Practices 
> (BCP) documents.
Based on this, the actual consent tokens must not be part of the
consent policy, otherwise these would also be shared between MTAs.
This seems like a way of compromising consent tokens.

> revoked. To enforce these rules the MTAs and MUAs may rely on various 
> other sources of data being provided either in the message body, by the 
> SENDER or from third parties on the Internet.
> 
> Two aspects must be kept in mind. First of all consent systems may grant 
> or revoke consent automatically based on the CONSENT POLICY. The policy 
> does not define consent only, it also defines conditions for 
> automatically granting and revoking consent. Additionally, machines 
> cannot perfectly reproduce human wishes and the CONSENT POLICY created 
> might not match exactly what the end-user wants especially considering 
> other CONSENT POLICIES such as the organization's and the ISP's.
> 
> 
> This involves subsystems within the communication system that enforce 
> the policy. The overall framework may involve multiple subsystems within 
> the policy enforcement component. This may involve fail-open or 
> fail-closed approaches. With a fail-open approach, the system must 
> identify messages that do not have consent. For example, this may 
> include approaches that determine the nature of a message based on its 
> characteristics or input from a collaborative filtering system. With a
> fail-closed approach, the system must identify messages that do have 
> consent and only allow those to be delivered. For example, consent may 
> be expressed by a policy, by a "consent token" within the message, or by 
> some payment that essentially purchases consent or delivery rights.
> This component provides deterrence to parties that consider violating 
> the policy by facilitating identification and tracking of senders that 
> violate the policy. This may require non-repudiation at the original 
> sender, the sender's ISP, or some other entities involved in the 
> communication system."
So far, so good.
> This category includes tools that let users express their consent 
> choices. The choices that the user makes are then translated into a 
> CONSENT POLICY which may be restricted by the software implementation, 
> the organization or the ISP. Today there is no one comprehensive plan or 
> language to express consent. Examples of such tools include:
> 
> Filter definitions
> 
All of them inadequate.
> This category includes portions of the MTAs/MUAs that enforce the 
> CONSENT POLICY defined for the end user as modified by the organization 
> and the ISP's CONSENT POLICIES. These tools are used while the SMTP 
> transaction takes place. Today there is no one comprehensive type of 
> tool to do that, instead combinations of tools are used. Examples of 
> these tools include:
> 
Am I correct in my understanding that the above tools represent
today's tools and not proposed tools? Do you have a section
for listing proposed tools?
> enforce policies; and by ISPs and LEAs for track down spammers. Today 
> there is no single comprehensive standard for this. Example of these 
> include:
> 
> In order for the consent model to operate properly, we need to define 
> the following items:
Great start. Could you use any assistance?

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 03 Jul 2003 22:50:45 -0400

At 08:01 PM 7/3/2003 -0600, Selby Hatch wrote:

>....

The whole policy cannot be shared with the sender since it will simply 
allow the sender to guess what kind of messages can go through UNLESS the 
policy relies on trusted third parties such as CAs for consent tokens.

>>be to inform the SENDER of lack of consent by the RECEIVER and to request 
>>a CONSENT TOKEN (if applicable). A CONSENT TOKEN is a piece of data 
>>exchanged between the RECEIVER and the SENDER, which will grant consent 
>>to the SENDER in accordance with the CONSENT POLICY of the RECEIVER. 
>>Examples of such tokens are C/R messages, hash cash tokens, e-postage, 
>>digital certificates, trusted sender seals (such as Habeas and 
>>BondedSender), etc.

A consent token is implementation specific - can be a key, certificate, 
etc. We will keep this in mind.

>on, the receiver grant consent to the sender?

The receiver gets a consent token and grants consent to the sender. 
Granting of consent may be accomplished by simply letting the email go 
through, or may require sending back a token. This sentence simply means 
that the receiver grants consent - whether a token is send back or not is 
implementation specific.

>>software being used, specifically the MUA and the MTA, might support only 
>>specific types of consent rules which will be used in creation of the 
>>policy. CONSENT POLICIES from multiple users maybe combined to create a 
>>combined CONSENT POLICY for the entire organization or ISP. The 

However it may be based or combined with policies of the ISP.

>This seems like a way of compromising consent tokens.

Some tokens can be shared - like public certificates.

>.....

Yes, this is listing today's tools. These three sections will list today's 
tools and proposals.

>>...

Definitely. There has been a lot of discussion much of which very relevant 
to this document. I might have missed things, so I definatly would 
appreciated a review of the document and any suggestions on style, order, 
spelling, content, anything!

Yakov

---

From: "Madscientist" <[email-masked]>
Date: Thu, 3 Jul 2003 23:09:39 -0400

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Yakov Shafranovich

>policy relies on trusted third parties such as CAs for consent tokens.

What if the policy included hinting such that a new inbound message
which does not satisfy the policy is rejected, but the rejection
includes a recommended alternative (a hint) for satisfying the policy,
or indicates precisely what part of the policy failed. This would allow
new anonymous senders to gain access via some means selected by the
receiver without exposing the receiver's policy to the sender.

For instance:

IRRQ (Intelligent Retry Request) does this by making a small alteration
to the SMTP protocol by rejecting the message with a temporary failure
(indicating that the policy was not satisfied) and providing a
one-time-password in the form of an email address that the sender may
include if they are legitimate. This is a variation on "greylisting".

==> RCPT TO: <[email-masked]>
<== Temporary failure, try again with <[email-masked]>

.... Sender waits a nominal period of time for the retry ....

===> RCPT TO: <[email-masked]>
<=== OK
===> RCPT TO: <[email-masked]>
<=== OK

This might be employed where the policy is for new unkown senders to
implement IRRQ. Other policies and response mechanisms could be applied
depending upon what is available and appropriate as selected by the end
user and the provider of the RECEIVER. This IRRQ example is just a "for
instance".

All forms of this kind of system ultimately become some kind of
challenge-response mechanism where the initial rejection is essentially
a challenge, and the appropriate follow up is essentially a response.

_M

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 4 Jul 2003 13:50:47 -0400

>I wrote up an document on the consent model 
	I think it would be good to strip from the document the general
discussion of the spam problem and focus on the technical framework. One
can assume that the nature of the problem is well understood -- the
"evils" of spam are well-known problems. As it stands now, the
discussion of motivation for the proposal simply makes the document much
larger without really adding much.
	Also, while I would certainly include a short (one-paragraph?)
section on motivation and ensure that the paragraph mentions spam, I
think the document should focus on "consent" not "spam." Ideally, spam
would only be explicitly mentioned in a short description of motivation.
The rest of the document should only talk about consent. The challenge
of the document is to define how consent is expressed and managed. Such
a framework can have value dealing with more problems than simply
providing part of a solution to the spam problem.
	In general, I think it is not useful to quote other documents at
length. Given hypertext, we're able to easily and effectively reference
other documents without burdening every document with large extracts of
others. Ideally, the consent framework would be a concise description
where every line had value on its own and wasn't simply a repetition of
data found elsewhere. The simpler the document is, the easier it will be
for people to understand it and evaluate it.
	I think there are some labeling problems in the current
document. For instance, a "lookup in a realtime black list" is not a
"policy enforcement mechanism." Rather it is a means for determining
some attribute of a message which can then be fed into the policy
enforcement mechanism. (i.e. Message has the "sent from blacklisted
node" attribute. Thus, the enforcement mechanism -- which is distinct
from the mechanism that did the blacklist lookup -- decides to reject
the message or put it in a graybox.) The same comment applies to most of
the other things mentioned in this section. They are all means to
discover attributes of a message -- it is only anecdotal that most
implementations of these methods are bound to specific enforcement
policies. The framework should clearly identify the distinctions between
components of a system.

		bob wyman

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 04 Jul 2003 17:53:36 -0400

I am thinking of reformatting the document along the lines of RFC 2778 
which defines a model for instant messaging. Tell me what you think.

Yakov

---

From: Walter Dnes <[email-masked]>
Date: Mon, 7 Jul 2003 01:54:13 -0400

On Thu, Jul 03, 2003 at 03:38:41PM -0400, Yakov Shafranovich wrote

> under which this process is done is best left to the implementors and the 

  I have one worry about this.  The suggested model seems to center on
what type of email, rather than from who, the receiver is willing to
receive.  First, I question whether one can come up with something
simple that'll specifically state that a consumer is looking for product
X (egg beater, lawn-mower, whatever).  Secondly, even if this could be
accomplished, do I really want to risk getting email from several
thousand businesses around the planet who are legitimately responding to
my request?  This is falling into the business/marketeering mindset of
"push"-marketing.  If I want something, I'll ask, fer-cryin-out-loud.
In that case, my consent will be for company X to communicate with me.

  Another reason for concentrating on *WHO* we receive from is that
corporate behaviour is remarkably consistent.  One person mentioned in
another message the example of Roving Software getting one bad customer,
and being blocked.  Guess what folks, Roving is blocked not only by a
DNSbls, but also by a lot of personal lists.

> Lookups in Realtime Black Lists (RBLs)
             ***************************

  I believe both the phrase and the acronym are trademarked by MAPS LLC.
The generic term is "DNS based list" (DNSbl would be the acronym).  Note
that I did *NOT* say "DNS-based blocking list".  A DNSbl can be used for
either blacklisting or whitelisting.

> Open relay testing (MAPS, RBLs, etc.)
  Trademarks again.

> Detection of hacked computers (Dshield.org, etc.
               ******
  "Compromised" is more appropriate.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 07 Jul 2003 02:25:54 -0400

>DNSbls, but also by a lot of personal lists.

Please take a look at the updated draft 
(http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html), 
these have been defined as:

CONSENT – an expression of wanting to receive specific email
LACK OF CONSENT – an expression of not wanting to receive specific email or 
absence of prior CONSENT

I agree with you that CONSENT has not been defined properly, I am wondering 
how we should redefine it properly.Maybe something like this:

CONSENT - an expression of wanting to receive email from a specific SENDER
LACK OF CONSENT – an expression of not wanting to receive email from a 
specific SENDER or absence of prior CONSENT for that SENDER

However, we need to take into account filters which check not for specific 
senders, but rather for specific types of email. Perhaps the two 
definitions above should be combined.

> > Lookups in Realtime Black Lists (RBLs)

Take a look at the updated draft, these items have been removed 
(http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html). I 
think that its better to keep the model abstract.

Yakov

---

From: "Eric Dean" <[email-masked]>
Date: Mon, 7 Jul 2003 11:01:20 -0400

Further defining taxonomy and models are always of value to a research
group.

How does this differ from a challenge/response system?

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Shafranovich
> Sent: Friday, July 04, 2003 5:54 PM
> To: [email-masked]; 'Paul Judge'; [email-masked]
> Subject: RE: [Asrg] 4. Survey of Solutions - Consent Model
>
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 07 Jul 2003 12:53:32 -0400

A C/R system is one of the tools that fit into the model.

---

From: "Madscientist" <[email-masked]>
Date: Mon, 7 Jul 2003 13:12:13 -0400

>CONSENT - an expression of wanting to receive specific email 
>LACK OF CONSENT - an expression of not wanting to receive 
>specific email or 
>absence of prior CONSENT
>
>CONSENT - an expression of wanting to receive email from a 
>specific SENDER LACK OF CONSENT - an expression of not wanting 
>to receive email from a 

In our R&D of Message Sniffer we've developed a model for consent which
fits very well in this discussion. I recommend that the ASRG adopt this
generalization of our model for defining consent:

There seem to be really 4 cases, so perhaps CONSENT should be defined
within these 4 cases:

1. CONSENT - a direct expression of wanting to receive email from a
sender.

2. SOFT CONSENT - an indirect expression of wanting to receive email
from a sender.

3. SOFT DENIED CONSENT - an indirect expression of wanting not to
receive email from a sender.

4. DENIED CONSENT - a direct expression of wanting not to receive email
from a sender.

NOTE: 2 and 3 are required to handle anonymous senders.

In the above also:

Direct Expression = an explicit white rule or black rule.

Indirect Expression = expression by the evaluation of some mechanism
chosen by the recipient including any kind of filtering engine.

Sender = defined by any combination of Sender IP or email route, Sender
address, or other Authentication mechanisms. The recipient may define
any of these that may be required to define a particular sender, and may
also define which authentication mechanisms (if any) are acceptable.

If all of the above are acceptable then a policy of consent could be
established and utilized in a very clear way:

FIRST: Each inbound message is evaluated first against the sender policy
to define "Sender" for the sake of evaluation. This definition may
include the "Unknown Sender" which would limit policy evaluation to
"SOFT" policies (2 and 3 above). Note also that "authentication
mechanisms" may be defined by the recipient to support DNSbl or other
services such as Bonded Sender mechanisms, or any other mechanisms that
may arise.

SECOND: The message is then evaluated against the consent policy to
define the case that matches the message. This includes (in case 2 and
3) the application of any evaulation mechanisms that the user may define
to evaluate the content of the message or evaluate it's other
characteristics.

THIRD: A specific action mapped to the identified case in the policy
should be executed. For example, reject the message, submit the message
to some process, redirect the message to some mailbox, some combination
of actions.

---

As SOFT evaluations can be difficult to quantify and must be open to new
mechanisms that become available in future I recommend that a "Consent
Definition Language" be developed that provides for specific actions
based on the evaluation of the message against the policy, and that in
SOFT cases (2 and 3) the "Consent Definition Language" be extensible to
take into account results that may be returned from the soft evaulation
mechanisms.

For example, some "tests" may return weights, others may return
probabilities, others may return categories of content, others may
return specific heuristics that fail.

However, in general there structure of a working policy model tends to
be  hierarchiacal so an XML based framework can be very efficient. As
XML is naturally extensible then so would a "Consent Definition Language
(CDL)" based on XML.

---

In the interests of sharing, proofing, and evaluating CDL based policies
there should be a mechanism for defining standarized representations of
tests. 

For example, specific DNSbl tests that are "well known" may have names
names defined for them where those names would be adopted by the
community in the same way well known ports are adopted for services. 

Any such namimg conventions should be an enhancemnet rather than a
requirement in the CDL. For example, if a recipient wishes to leverage a
DNSbl (or other service) that does not have a "well known name" then the
definition of the test in the policy should be clear and consistent and
no more difficult to implement in the CDL than any other DNSbl. 

Similar guildelines should be in place for the implementation other SOFT
mechanicsms that might be used for: authentication (defining the
sender), or developing SOFT CONCENT (such as filtering systems such as
Message Sniffer, Spam Assassin, Bogo Filter, and others...)

---

Based on personal experience, the framework defined above _should_ be
able to encoumpass all of the current and proposed mechanisms used for
curbing abuse without significant difficulty or complexity.

If my description is unclear the I could create a generalized draft
policy to illustrate. Such a draft might then be extended and co-evolved
with an RFC defining the consent model. (I don't have the resources to
take on the full task, but I could certainly help.)

_M

Pete McNeil (Madscientist)
President, MicroNeil Research Corporation
Chief SortMonster (www.sortmonster.com)

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 08 Jul 2003 23:41:14 -0400

At 12:37 PM 7/8/2003 +0100, Andrew Akehurst wrote:

>Quoting Yakov Shafranovich <[email-masked]>:
>
> >> I have one worry about this.  The suggested model seems to center
> >> on what type of email, rather than from who, the receiver is willing
> >> to receive.
>
>   ... 8< ...
> >
> > LACK OF CONSENT  an expression of not wanting to receive email from a
>Are you saying we need not distinguish between a lack of prior consent and an
>explicit desire not to receive e-mail from a particular sender? In the former
>case, we don't know if the receiver wants messages from that sender or 
>not. In
>the latter case we know for certain the receiver does not want messages from
>that sender.
>....

I think this point was mentioned before by someone else. We do need to 
distinguish between lack of prior consent and express NON-consent. I 
believe Paul McNeil stated them as follows:

1. CONSENT - a direct expression of wanting to receive email from a sender.
2. SOFT CONSENT - an indirect expression of wanting to receive email from a 
sender.
3. SOFT DENIED CONSENT - an indirect expression of wanting not to receive 
email from a sender.
4. DENIED CONSENT - a direct expression of wanting not to receive email 
from a sender.

 > ........
 >In the ultimate scenario where everyone uses some implementation of this
 >consent framework it would be fine to make no distinction. However for the
 >purposes of interoperability with non-compliant systems during roll-out 
of the
 >new consent framework
 > ........

The "new" consent framework is not replacing the current structure of the 
Net. It is an ABSTRACT model that allows us to evaluate all anti-spam 
proposals. Also, it focuses on the giving the receiver power over his 
email. However, this would remain running within SMTP as it is today until 
SMTP is replaced with something else (if ever). However, since many people 
believe the nature of the spam to be tied to the open nature of the 
Internet, that would mean that spam will always remain a problem and 
consent systems will simply provide the tools for dealing with the problem 
on the receiver's side.

Yakov