Hello,
I read the discussion from Juli 2007 about the reject concerns. There
is still something that is not addressed in
draft-ietf-sieve-refuse-reject-06 -- early evaluation of scripts.
Of course it s possible to, say, evaluate a script that only uses envelope
"from" tests at the MAIL FROM stage, or to evaluate a script that only uses
envelope tests at the RCPT TO stage, but I really have to question the utility
of an extended discussions of the issues surrounding using sieve this way. The
overwhelming majority of scripts we end up with in practice make extensive use
of header and other tests that depend on message content and henace cannot be
evaluated until after the DATA phase.
And while the reject action is almost certainly the case where early evaluation
offers the most advantage, it isn't the only test or action where early
evaluation brings up issues, some of them fairly subtle. Consider spamtest - it
is possible in many cases to compute a spam score based solely on envelope
information. But better results are usually produced if content is considered.
So how should this be handled? Should
require ["spamtest", "reject, "relational", "comparator-i;ascii-numeric"];
if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
{
reject "Keep your spam";
}
be evaluated at RCPT TO when possible, or should it have to wait until after
DATA because a better score is available then, or perhaps it should be
evaluated twice? And all this totally ignores the implementation issues with
actually using exist spam filtering software with only an envelope.
Now, has the issue of early evaluation been one described in the sieve base
specification and given due considerstion in all the other sieve documents (the
currentdate test defined in date-index is an obvious example of a place where
such considerations should be described), not only would I have no problem with
adding such a discussion to this document, I would have insisted on it. But
that's not now things are. We haven't dealt with this concept at all and IMO
trying t do so as s side note in this one extension is not a good idea.
If early evaluation is indeed of sufficient interest to warrant specification
then the way to handle it at ths point is with an additional informational
specification. But as I stated previously, I am dubious that's there's
sufficient operational utility here to bother.
Ned