ietf-asrg
[Top] [All Lists]

[Asrg] 4. Survey of Solutions - Consent Model

2003-07-03 12:40:33
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg