-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]
On
Behalf Of Yakov Shafranovich
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.
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)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg