On Thu, Feb 03, 2005 at 04:14:34PM -0500, Cyrus Daboo wrote:
FYI the draft for the new version of the spamtest extension is now
available.
Picky comments from mem..
I have a hard time reading this document, mainly because of phrases
that include "returning strings" and overloading of some words to
mean different things. Perhaps it's just the way my brain works,
or doesn't work. Specifically:
1. Introduction and Overview
> The purpose of this document is to introduce two SIEVE tests that can
> be used to implement 'generic' tests for spam and viruses in messages
> processed via SIEVE scripts. These tests return a string containing
> a range of numeric values that indicate the severity of spam or
> viruses in a message, or a string that indicates the message has not
> passed through any spam or virus checking tools.
When you talk about SIEVE tests, it reads as though you are talking
about SIEVE language elements. Those elements won't really do those
things, it's the underlying filter implementation that would interpret
the result of spam or virus analysis and produce, conceptually, a string
(or strings) that can be used by those SIEVE language elements. (The
next sentence says as much.) Also, that conceptual string probably
contains "a number that lies within a range of numeric values" -- the
string would not contain "a range of numeric values."
3.1 General Considerations
> The "spamtest" and "virustest" tests described below both return a
> string that starts with a numeric value, followed by an optional
> space (%x20) character and optional arbitrary text.
Here's where the trouble really lies. This pretty clearly is talking
about SIEVE language statements -- and if it isn't, then the use of
those words is even more of a problem. Those statements do not return a
string; they act upon the string that was returned by the underlying
tests. (Or, rather, they act as if they did that: no string really has
to be present.)
> The additional text can be used to carry implementation
> specific details about the tests performed and descriptive comments
> about the result. Tests can be done using standard string
> comparators against this text if it helps to refine behaviour,
Does "this text" refer to "The additional text" or to the entire string?
The English grammar implies the former, but text in the introduction
implies the latter. For example, given a underlying spam test result
of:
"4 too many recipients"
how does:
if spamtest :is "too many recipients" { ... }
evaluate? IMHO testing against the "additional text" would be the most
useable.
> The "spamtest" test evaluates to true if the spamtest result matches
> the value. The type of match is specified by the optional match
Another example where the word "spamtest" means two different things:
the SIEVE statement and the underlying test that produces a string for
use by that statement. I'd recommend finding different ways to
refer to the SIEVE statement and the underlying analysis of spam and
virus results.
[ Imagine similar comments about similar sections ... ]
BTW I think this is the kind of extension that could be solved with
better fundamental language elements and/or better coordination between
language extensions.
For example, one could build on the proposed "variables" extension by
imagining a new set of read-only variables within specific namespaces
(per the old namespace idea, a la dates and timezones). Imagine:
require "variables";
require [ "relational", "comparator-i;ascii-numeric" ];
set "spamval" "${spamtest::value}"
set "spampct" "${spamtest::pctvalue}"
set "spamtext" "${spamtest::text}"
if string :value "ge"
:comparator "i;ascii-numeric"
"${spamval}" "3" { ... }
if string :value "ge"
:comparator "i;ascii-numeric"
"${spamtest::pctvalue}" "30" { ... }
Time travel might be required though.
mm