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

From: [email-masked]
Date: Tue, 15 Jul 2003 00:25:16 -0500

>>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 think that at various stages of incoming message triage there are various 
things that need to be done, and there is at least some natural ordering of 
those operations that ought to take place.

First and foremost, I think there needs to be things that are strictly 
envelope/header related.  There might be some specific and familiar senders 
whose messages are NEVER to be delivered, or whose messages are ALWAYS going to 
be delivered (although perhaps with subsequent modifications!), and there might 
be some messages (many, in practice) which can't be decided or handled on the 
basis of header alone.  Sometimes individual message header lines will need 
examination and qualification.

Second, messages often consist of multiple parts.  Those parts can require 
individual, further attention... decoding, name and format testing, content 
scanning, or whatever.  In some cases, a multipart message needs to have one or 
more parts removed;  it's even possible that an originally multipart message 
might be reduced to a single-part message before releasing the message to the 
mail client software or ongoing MTA.  

Third, both within individual parts and within entire messages I think there 
needs to be provision to call external processing modules (which might be user 
or corporate-written) to provide additional decision-making options.  These 
might be individual batch-type processes, or DLLs, or Web services, or any of a 
variety of other technologies.  The important thing is that the processing of 
messages can be customized by user-written code in a multitude of ways.

>>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

I think that "LACK OF CONSENT" needs to be further qualified with DENIAL (an 
expression of NOT wanting to receive mail from a specific, known sender) as 
opposed to simple "not (yet) authorized".

>>However, we need to take into account filters which check not 

[only just]

>>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.

I'm not sure I understand here (yet?) the point being made with "direct" versus 
"indirect" on these first two cases.  Is #2 a "default - unrecognized sender" 
situation and #1 a known sender from which mail is ALWAYS desired (i.e. 
"whitelist")?

> 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.

Likewise...?

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

I think that 2 and 3 also might be required to handle cases where a qualitative 
decision is made (i.e. messages not specifically "whitelisted" or 
"blacklisted").

But there are further cases that you're not considering here, and that is at 
least equally important.  It's not just whether a message is actually desired 
for delivery, but also how to handle cases where a message is NOT to be 
delivered to the original addressee.  Is the message to be simply blackholed?  
Is a forged "destination mailbox unknown" reply to be returned?  Is a polite 
reply to be returned requesting that the message be resent without attachments 
or HTML or encoding or whatever?  Is the message simply to be bounced back?

> 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.

Ah, okay.

> Sender = defined by any combination of Sender IP or email route, 

Might it be useful to provide for coherency of message routing?  e.g. a message 
with a From: address of HOTMAIL.COM or AOL.COM but which has passed through a 
mail server or relay (say) in China or Korea or some other distant country?

Or, say, a message with wildly incoherent dates in Received: headers or Date: 
header?

> 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.

Note that this might not be only based on the headers.  In particular, one might 
require that a message from a certain original sender MUST be signed with that 
sender's specific sig file or PGP key or something in order to be considered 
"authenticated".

Certain senders (say, specific Yahoogroups mailing lists) for instance might 
NEVER legitimately contain attachments.  If someone spoofs a popular Yahoogroups 
mailing list as the "sender" but actually still sends an attachment (which that 
group should NEVER be sending) then that's evidence of a forged From: address 
and/or an unauthenticated sender.

> 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.

In the ultimate case of this, you really end up wanting to write a program... do 
we need yet another programming language?  Personally, I'd favor the use of 
SPITBOL for stuff like this... it's probably about the most powerful language 
there is for text processing and pattern recognition and data structure 
manipulation... and that's what this whole process is really all about.  SPITBOL 
has the additional nice property that one can bring in new program segments 
dynamically according to stages already passed or decisions already made... so 
that the program can be easily extended at runtime to add new rules or whatever, 
based on (say) specific senders or specific types of message content.

It's hard to imagine how one would devise a specific "Consent Definition 
Language" that doesn't end up being in essence a "programming language" (and 
that's NOT a bad thing, necessarily, but I'd hate to see the "standard" set to 
use a specific language, especially if that language ends up being less 
satisfactory for this use than something already existing such as SPITBOL or 
whatever).

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

Sure.  And some processes might need the intermediate results resulting from 
prior processing.

Others might be independent, and in that case it would also be nice to allow 
multiple tests on the message to perhaps proceed in parallel 
(multitasking/multiprocessing/whatever) so as to reduce overall time spent in 
processing each message.

> However, in general there structure of a working policy model tends to
be  hierarchiacal so an XML based framework can be very efficient. 

I've heard XML called a LOT of things although I don't think that I can remember 
too many times that it was accused of being "efficient".  :-)

Just because XML is presently trendy is NO reason IMHO to impose that degree of 
overhead onto anything as core as E-mail processing.  In another list I'm on 
we've been discussing the XML overhead/performance issues and found that a 
typical situation results in XML record descriptors taking twice as much time 
(or more) than a simple delimited data representation.  (And I think that it 
often can take a LOT more than even that...)

> As XML is naturally extensible then so would a "Consent Definition Language
(CDL)" based on XML.

Honestly, there is nearly NOTHING that is especially more "extensible" about XML 
than there is with MANY other data representations.

I have a number of objections to XML in principle, largely based on the fact 
that individual field names have to be parsed again and again for EVERY record 
handled... and not just field names, but also the higher-level issues of 
ensuring that every required field is present for every record...

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

Ultimately, again, this is going down a slippery slope to defining a new 
programming language... and I simply don't think that's necessary here.  There 
are a number of languages that could be used, from primitive languages like C to 
braindead RegEx-based things like Perl or "real" pattern-matching languages like 
SNOBOL or SPITBOL.

Ultimately, I suspect that individual implementations are likely to be done in 
whatever language the implementor is most comfortable with.  That's perhaps the 
way it should be.  Despite the fact that I *personally* think that SPITBOL would 
be *wonderful* for writing stuff like this, I recognize that a lot of people 
aren't familiar with it and would probably pick Perl or something instead just 
because that's all they know.  

I'm not even sure, really, that we have to go all that far in terms of defining 
what the actual consent definition language or corresponding data 
representations are... I'm not all that convinced that we'll ever see (or even 
that we SHOULD) a single standardized worldwide agreement for stuff like this, 
and different mail filtering systems and tools are likely to develop their own 
approaches and techniques.  (And if someone does a distinctly "better" one, 
hopefully it will win out even over a "standard" one.)  

> 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. 

I think it probably makes more sense to simply provide a mechanism (or better, 
several) for calling external processing units.  Then the script (or whatever) 
can add whatever steps a person wishes.

Again, though, a lot of these are implementation issues within a particular 
filter;  I'm not sure we have to produce anything to that level.

> 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...)

Good examples of external procedures which might be used within the consent 
model.

> 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.

Perhaps, although it sounds awfully complex to me (and specifically I really 
don't see why we need to jump onto the currently-trendy XML bandwagon here).

The real issue, I think, is how far we're going to go toward writing the actual 
filtering application as part of the consent model standard (and even, for that 
matter, whether we NEED a standard consent description).  

Even just simple "whitelists" or "blacklists" don't always tell the story... for 
example, I might have a Yahoogroup I'm a subscriber to but that group (which I 
might whitelist) should **never** send me a message containing (say) an 
executable attachment.  If it does, I definitely want to (at a minimum) trash 
the untrusted attachment.  

Likewise, the mere presence of a blacklisted domain reference in a message may 
not be enough to justify t-canning the message... for instance, the messages I 
get from the suespammers.org domain might refer to a particularly heinous 
spammer or quote from one of their E-mail spams, and I wouldn't want to t-can 
the message just because of that.

I guess I personally feel that what we need to do more is to establish that 
there are certain broad areas that will typically be used to perform triage on 
incoming E-mails, whether at the user level or at the domain or ISP service 
level.  These areas include header-level coherency and tests (acceptable user 
identity, no routing through known open relays, etc) as well as content-based 
tests (no HTML-burdened content, no obscured URLs, no bogus HTML tags, no 
obscured content tricks, no embedded images, no known-disreputable URLs or 
domains or IP addresses, no attachments (or maybe no executable attachments) etc 
etc) and that we need to provide for different sender-specific rulesets for 
specific authenticated familiar senders, specific familiar disreputable senders, 
and unfamiliar senders.

I still think that it is absolutely essential that HTML-burdened content (or at 
least large classes of frequently-abused HTML) and presence of attachments or 
encoded message text should be offered as an optional (and probably 
recommended!) cause for denial of delivery of messages from unfamiliar senders.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: "Pete McNeil" <[email-masked]>
Date: Tue, 15 Jul 2003 10:32:57 -0400

>those operations that ought to take place.

I agree. However the ordering may not follow the processing of an
incoming message. We may need to use a subsumption architecture to allow
policies to syncrhonize with the way the email system implementing that
policy operates.

>envelope/header related.  There might be some specific and 

The basis of a consent policy is most naturally expressed as a hierarchy
of rules rooted in the sender - so the first step in implementing a
policy is to define "SENDER". Envelope and header information are
generally the right place to start, but they don't always establish the
SENDER by themselves.

>mail client software or ongoing MTA.  

I'm not sure it makes sense for the consent policy to get involved in
modifying the message in any way although I do agree that establishing
the correct policy to execute may require some decoding.

>needs to be provision to call external processing modules 

In order for a consent policy to be an open document it must be possible
to establish a collection of "tests" to establish the inputs required
for executing the policy, and also some "actions" for responding to
policy decisions. Both of these will be somewhat implementation
specific.

In an open architecture, which I believe can be expressed in an XML
compatible format, "tests" and "actions" would be defined with
implementation specific definitions.

(The following introduces the idea that CONSENT can be based not only on
SENDER but also on other "features" that can be defined in the POLICY.
The new, obvious feature here is content... with the idea being that a
RECIVER might grant CONSENT to a SENDER only for specific CONTENT. It's
important to realize that the rules are only formally based on specific
tests and that CONTENT is only a policy-specific concept implemented by
a combination of tests... if required.

Completely artificial example/illustration:

<TESTS>
  <TEST>
    <NAME VALUE="PORNOGRAPHIC" />
    <IMPLEMENTATION>
      <EXECUTE>
        <PROGRAM VALUE="/usr/bin/heuristic-test" />
        <PARAM1 VALUE= $MESSAGE />
      </EXECUTE>
      <VALUE>
        <TYPE VALUE=BOOLEAN />
        <TRUE>
          $RESULT = 54
        </TRUE> 
      </VALUE>
    </IMPLEMENTATION>
  </TEST>
<TESTS>

...

I had to bake that on the fly, I hope it makes sense.

Presumably, the above defines a TEST for the content of a message based
on an program that uses heuristics. The program
"/usr/bin/heuristic-test" is called with one parameter which is the
message itself ($MESSAGE). The TEST is TRUE if the $RESULT code of the
program is equal to 54.

The test could just as easily been based on some feature of the MTA
software (such as a DNSbl lookup), some environment variable, etc...

The concept is that defining the SENDER and the CONTENT requires that
some TESTs be executed. These TESTs should be defined in an way that is
implementation specific. Similarly the ACTIONS should also be defined
this way. This allows the POLICIES section to be shared anywhere that
the TESTs and ACTIONs named in the policy can be executed, and allows
those TESTs and ACTIONs to be defined for each system independently.

There should also be some "well known" tests that MUST be implemented in
order to be compliant... these would be tests such as the connecting IP,
envelope information, header information, etc.

>situation and #1 a known sender from which mail is ALWAYS 

Yes. Ultimately these are only conceptual constructs. A policy always
establishes a boolean CONSENT or DENIED CONSENT for a given message,
however in establishing a definition of how a policy document works it
is useful to distinguis between CONSENT which is based on a known sender
and SOFT CONSENT which is based on an evaluation of a message from an
unknown sender. The primary differnce between them is the relative error
rate.

With SOFT CONSENT / SOFT DENIED CONSENT the policy is more likely to err
so the ACTIONs that are taken in these cases should be "softer". Note
the careful use of _should_.

While it is possible for a given policy implementation to delete any
messages that fail a given DNSbl or heuristic test if that fits the
needs of the RECEIVER, the RECEIVER would be wise consider that such a
harsh policy might have unintended consequences due to the error rates
of these tests. As a result they _should_ chose a less aggressive ACTION
in these cases such as rejecting the message or holding the message for
review.

>> 4. DENIED CONSENT - a direct expression of wanting not to receive 

Consider case 1 and 4 (CONSENT / DENIED CONSENT) like a white and black
rule respectively. There is no room for interpretation (save that which
determines the SENDER)

Consider case 2 and 3 (SOFT: CONSENT / DENIED CONSENT) like a collection
of tests that attempt to evaluate the message based on content and other
rules... These tests will have a varying degree of confidence in all
cases.

>decision is made (i.e. messages not specifically "whitelisted" or 

Yes. Even if you know the sender, you may want to decide CONSENT based
also on some other grounds... The policy model must support this.

>or HTML or encoding or whatever?  Is the message simply to be 

A policy will define ACTIONS that can be taken when consent is granted
or denied. The ACTIONS would be defined in an open way just like the
tests and would be dependent on the facilities available with that
implementation.

The policy would be able to define any of these actions once consent was
granted or denied, and would presumably define these actions based on
parameters that were established by the tests defined in policy.

something like:

<TESTS>
  ... # Definitions for test implementations on this system.
</TESTS>

<ACTIONS>
  ... # Definitions for action implementations on this system.
</ACTIONS>

<SENDERS>
  ... # Definitions of senders (by applying tests)
</SENDERS>

<CONSENT>
  <GRANTED>
    <ACTION-POLICY>
      <USE-ACTION VALUE=DELIVER />
      ... # Definitions of sender cases.
    </ACTION-POLICY>

    <ACTION-POLICY>
      <USE-ACTION VALUE=REDIRECT />
      ... # parameters.
      ... # Definitions of sender cases.
    </ACTION-POLICY>

    <ACTION-POLICY>
      <USE-ACTION VALUE=COPY />
      ... # parameters
      ... # Definitions of sender cases.
    </ACTION-POLICY>

  <DENIED>
    <ACTION-POLICY>
      <USE-ACTION VALUE=BOUNCE />
      ... # Definitions of sender cases.
    </ACTION-POLICY>

    <ACTION-POLICY>
      <USE-ACTION VALUE=BLACKHOLE />
      ... # Definitions of sender cases.
    </ACTION-POLICY>

</CONSENT>

>Or, say, a message with wildly incoherent dates in Received: 

Such as: (Another half baked example)

<SENDERS>
  <SENDER>
    <NAME VALUE="FORGED-AOL>
    <TEST>
      <SENDER-DOMAIN> AOL.COM </SENDER-DOMAIN>
      <OR> # Tests use boolean AND by default
        <ROUTED-THRU> China </ROUTED-THRU>
        <ROUTED-THRU> Korea </ROUTED-THRU>
      </OR>
    </TEST>
  </SENDER>
</SENDERS>
...
<CONSENT>
  ...
  <DENIED>
    <ACTION-POLICY>
      <USE-ACTION VALUE=BLACKHOLE />
      <USE-ACTION VALUE=LOG-DENIED />
      <CASE>
        <SENDER VALUE=FORGED-AOL />
        <SENDER VALUE=FORGED-HOTMAIL />
      </CASE>
    </ACTION-POLICY>
    ...
  </DENIED>
</CONSENT

>and/or an unauthenticated sender.

The existence of an attachment on the message could be a test and that
test would be used to define the SENDER for this yahoo group. If the
message had the attachment then the SENDER definition would not match
and the policy would be denied by default - more specifically the
UNKNOWN sender would be selected and the action policy for that case
would be executed.

>we need yet another programming language?  Personally, I'd 

I think what we want to do is establish a standard policy document in
XML format and then allow the implementor to include any tools,
programming languages, tests, etc... that they wish to.

The purpose of a "compliant" consent policy is to standardise the
definition so that consent policies can be aggregated, shared, and
discussed, and so that there is a "standard" framework for developing
"abuse management" tools for email.

>favor the use of 

I may wish to use Java, someone else may wish to use Lisp, and so on.
The standard consent policy document should allow for any or all of
these to be implemented as features of the local system. In my current
thinking this is done in the TESTS and ACTIONS section where the
implementor can define any number of external or internal program
features that they might make available.

>based on (say) specific senders or specific types of message content.

Presumably an advanced implementation of a "standard consent policy"
would optimize test execution dynamically at runtime and would take
advantage of any features that are available in their software.

One caveat to this, however, is that highly specialized implementations
may not be easily transported to other systems and may not be shareable
beyond the confines of the local system.

This has implications regarding the aggregation of consent policies -
which can be a very powerful feature of a "standard consent policy"
framework. Aggregated consent policies would allow common user policy
decisions to be moved toward the gateway MTAs of a large system with
profound implications for resource utilization.

Highly proprietary implementations may not travel well... the result
would be that policies dependent on TESTS or ACTIONS that are not
available to the common policy would not be aggregated.

This open architecture allows for highly specific implementations -
however those who use proprietary TESTS or ACTIONS will need to
understand the implications of those decisions.

>Language" that doesn't end up being in essence a "programming 

I think it's possible... in fact it's probably done (see above). I'm
fairly certain that the language I'm proposing can be defined without
defining any specific programming language - and, in fact, that would be
the point.

>(multitasking/multiprocessing/whatever) so as to reduce 

My current thinking is that the language "presumes" all required tests
are executed before a SENDER is defined (based on the results of those
test). Then the correct ACTION-POLICY is implemented based on those
results.

The reality would be implementation specific. One would presume, for
example, that a highly efficient implementation would execute only those
tests required to establish each case, and that the order of test
execution and policy selection would be established so that the least
amount of processing would be required for each case.

For example, if there is a sender defined by the connection IP and that
sender has a normal delivery action policy then the engine would first
test for the connection IP and having discovered that the IP matches
this policy would immediately deliver the message - eliminating all
other tests.

HOWEVER - all of that would need to be implementation specific.
It is very important for the policy definition langage to remain
agnostic on implementation and programming languages if there is to be
any hope for wide adoption.

>too many times that it was accused of being "efficient".  :-)

Well, it does at least fit the bill here. It is extensible by design,
and it is fairly well understood and usually easy to grasp (look how
well HTML cought on), and it translates well into databases, parsers,
etc. So, on the whole I think it's the most efficient for this task.

Mind you - I'm not saying that everyone, or ANYONE, should learn XML and
the consent policy definition language... Presumably those who build
software that implements these policies would make nice, simple, slick
GUI tools for users and admins to establish policies etc. The important
thing is that those poilices can be expressed in a standard way so that
they can be shared, aggregated, and discussed easily.

>often can take a LOT more than even that...)

One would presume that the XML would be parsed once when the policy
chages or the system starts and after that a highly optimized engine
would simply execute the tests and actions defined in the document.

HTML, for example, is not necessarily a very efficient way of defining
documents when measured in some ways... however it is very easy to
deploy and leverage... that's what I'm going for here.

>I have a number of objections to XML in principle, largely 

Make another recommendation then and have it compete on it's own
merrits. I'm not particuarly "fond" of XML either, nor am I any expert
on it, nor do I have any investment in it.

HOWEVER, as an engineer I recognize that there are a lot of tools out
there to work with XML, that it is a widely accepted standard, and that
it has a number of characteristics that are beneficial to this task.

If there is a better choice then we should go with it. Right now, I'm
sticking with this because at the very least I think the structures I'm
proposing with this language are sound and would likely be implemented
in whatever language is selected to represent them.

>pattern-matching languages like 

I think you're missing an important point. All of the languages you are
talking about are procedural in nature. A policy should not be
procedural because it's purpose is to capture a policy, not a procedure.

Specifically the "root" construct of the problem at hand is:

I want mail that is like this.
I don't want mail that is like that.

A procedural language is required _under the covers_ to implement the
policy, but the poicy itself should not be defined procedurally.

This is the same kind of separation that makes SQL powerful for managing
data. The user of SQL does not need to understand how the data is
stored, nor how it can be accessed, nor what the most efficient search
mechanisms might be for their system.

Rather, they simply say: "Give me these records"... or more precisely:

Select * where x="these records";

Does that make sense?

---

In the same way, a system administrator can establish a number of TESTS
based on the features at their disposal... Some of these might even
execute perl scripts, C++ programs, SPITBOL or other engines. But in the
end, the user (or administrator) defining the policy only needs (or
wants) to say:

"I want mail that passes these tests."

Some of the tests should be on the _MUST IMPLEMENT_ list for a compliant
system. Specifically those that are "well known" and defined by this
group (and the group(s) that eventually manage and contribute to a cdl).

For example the test for a specific connecting IP or network.

>hopefully it will win out even over a "standard" one.)  

You may be right, but I think it's a good idea. If for no other reason
than it will provide us with a "common language" for discussing the
different policies we may have or may propose, and the implications of
implementing those policies.

I've seen a lot of chaos on this (and other lists) because there is not
yet a common language for defining policies. The cdl I've proposed does
that, and more - it provides the groundwork for what could become a
common standard for implementing policies. Whether it succeeds in the
latter or not, the benefits of the former are significant.

>able to encoumpass all of the current and proposed mechanisms 
>used for curbing abuse without significant difficulty or complexity.
>

"trendiness" is no reason to reject a possible solution.

>Even just simple "whitelists" or "blacklists" don't always 

The point of defining a CDL is not to specify, recommend, or define any
specific whitelists, blacklists, or other tests. Rather it is to define
a standard framework within which those tests can be defined and how,
once defined, they can be applied.

>example, I might have a Yahoogroup I'm a subscriber to but 
<snip>
>Likewise, the mere presence of a blacklisted domain reference 
<snip>

One goal of a CDL is to provide a framework where *almost* any policy
could be described - even the complex policies you describe.

>tests (no HTML-burdened content, no obscured URLs, no bogus 

In the CDL I propose, all of these would be TEST definitions. With a CDL
in place it would be easier for us to discuss, contrast, and explore
these definitions.

At the same time, we would be able to explore the implications of
policies based on these tests.

In the same way we can use the CDL to explore TEST we can also use it to
explore ACTIONS.

That's what the CDL is really for... It is only a hope that the CDL
would be translated into actual systems that implement policies
researched, reccomeneded, and documneted by this and other groups using
CDL.

>recommended!) cause for denial of delivery of messages from 

That is a policy proposal. With a CDL, you could be _very precise_ about
what you mean by this proposal and everyone would be able to discuss it
in a common framework.

I hope I've cleared things up... It was not my intent to be combative if
any of my comments appeared that way.

Thanks,

_M