[Asrg] 4. Survey of Solutions - Consent Model

[Yakov Shafranovich <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg