Quoting Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>:
At 03:34 PM 8/30/2003, Andrew Akehurst wrote:
Recently I posted a message on the topic of tests and actions for
XML-CPDL inspired by those defined by RFC 3028 for Sieve.
.......
Here is a link to an Internet draft defining a spamtest extension for
Sieve:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-03.txt
Thanks Yakov. It's an interesting approach to separating the
implementation from the policy definition. However I have
reservations about its ability to be shared between systems
in a broader consent framework.
Section 5.2 states:
SIEVE implementations that implement the "spamtest" test
have an identifier of "spamtest" for use with the capability
mechanism.
The "spamtest" test evaluates to true if the spamtest result
matches the value. The type of match is specified by the
optional match argument, which defaults to ":is" if not
specified.
The spamtest result is a string starting with a numeric value
in the range "0" (zero) through "10", with "0" meaning the
message is definitely clear of spam, and "10" meaning the
message is definitely spam. The underlying SIEVE
implementation will map whatever spam check is done into this
numeric range, as appropriate. If the message has not been
categorised by any spam checking tools, then the spamtest
result is "NIL".
This would undoubtedly be fine in the context of a single MUA
but it's not readily reusable elsewhere.
The reason is that the terms "underlying SIEVE implementation"
and "as appropriate" involve a certain amount of hand-waving.
It specifies nothing standard about what that underlying
implementation is required to support, nor about how such a
mapping is to be made.
For example, I could use SpamAssassin on my local system, but
there's no guarantee of what spam tests would be performed
elsewhere nor how those tests would be scored. Since I
couldn't predict the effects of having the policy enforced
elsewhere, it would only be useful on my local machine. So
this Sieve extension may be useful locally but it's no help
for sharing consent policy information.
I've been awaiting some feedback on the XML-CPDL tests and
actions I proposed last week:
http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg07113.html
Does the lack of responses indicate agreement or simply lack
of interest from members of this list? We need volunteers to
help move this area forward.
Thanks
Andrew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg