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