Hello,
>> About the spamtest issue: it shall be evaluated after data.
>
> Why? What if the necessary information is already available and nothing
> in the message body is capable of overriding it? Why would a ban on early
> evaluation of scripts that use spamtest make any more sense than a
> ban on early evaluation of scripts that use reject?
Doing heuristic spam analysis can combine a lot of rules, some giving
positive and other negative weight on the result. The fact that the
envelope increases the spaminess, does not mean that the body of the
message will not decrease it. At the end the total spaminess can be
acceptable for the recipient, even if the envelope went above the limit.
So to be accurate, the spamtest shall be done after DATA .
Sigh. All of this is completely obvious and completely irrelevant. For the
third time, there can be cases where the analysis done on the envelope is
sufficient and no, repeat NO, analysis of the message content is capable of
overriding. In such cases the message might as well be refused at the envelope
stage and making some arbitrary rule saying this mustn't be done is every
bit as inappropriate as the rule against doing envelope time rejects
you're arguing against (despite the fact that no such rule exists).
In the cases when the spam software works only on the envelopes, or
cannot decrease the spaminess due additional rules, then spamtest can be
evaluated before DATA as well.
Which is exactly what I've been saying from the start.
>> If I
>> remember correctly, there was an idea to extend the envelope test to
>> check against the sending host (apart from sender and recipient) and
>> check using external lists if the sending host is blacklisted.
> However, no such extension has been defined or even, aside from a passing
> mention, discussed.
Ned said on 8th October 2007 to look on
draft-freed-sieve-environment-01, when it comes out, as the idea of
remote-host and remote-ip will be presented there. Right now I see it is
really at http://tools.ietf.org/html/draft-freed-sieve-environment-01.
Correct, but the environment extension gives you access to the necessary
information but doesn't do the whitelist/blacklist part, which necessary for
this to gain any sort of equivalency with spamtest.
I actually favor the more general approach described in the (now expired)
draft-melnikov-sieve-external-lists-01.txt, modulo a few changes I suggested
on the list some time back. This provides a generic external list access
mechanism which can be usedd for all sorts of different purposes.
However, now that you have brought up environment, its another extension that
potentially interacts with early evaluation in interesting ways. I hadn't
really thought about it before and the initial set of environment items doesn't
include anything that depends on message content (nor do any of the exxtensions
we''re planning on implementing), but it is not beyond the realm of possibility
that some environment item might be defined that could not be evaluated at RCPT
TO time.
>> > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
>> > fetch the sieve script as part of verifying that the rcpt to address
>> > exists, and evaluate until some test fails for lack of data. I think
>> > the draft as it stands is fine.
>
>> I think this is wrong, as it does not allow combining keep and reject.
>
> I fail to see anything in this implementation description that would
> create a
> problem for combining keep and reject. And even if it did, since the draft
> strongly recommends implementations to forbid this combination (our
> implementation definitely does this), I fail to see the point of any of
> this.
If reject is done at RCPT time and there is no DATA afterwards (due the
lack of accepting recipients), keep cannot be made. (Keep what?)
The need of combining keep and reject was addresses in the discussion
from 2006-07-11 as a sort of logging the process.
Yes, I recall the discussion. I still think its a totally bogus thing to do and
the draft still recommends that they be incompatible.
>> The reject action shall be executed after RCPT TO:, if the script
>> terminated successfully (= reached <EOF> or stop; without making
>> header/body tests, or invoking the keep action) being executed there.
>
> This goes much too far - it actually recommends if not requires
> implementations
> implement early evaluation - and I am adamantly opposed to it.
This is my view on Arnt's FWIW: Arnt said that reject is executed, if no
test or actions failed before reaching "reject". I answered, that this
approach does not allow to combine keep and reject/fileinto and
reject/notify and reject/whatever and reject. Instead, reject shall be
applied during early evaluation only if the script terminates
successfully. (The other option is to make reject if no actions/tests
failed yet).
OK, got it. Arnt has already clarified that this is in fact a nonissue for him.
It is for us as well - we don't stop evaluating at reject or anything else for
that matter besides stop or an error of some sort.
Ned