Re: action reject and smtp RCPT TO:

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

        Greetings,
                Dilian