[Top] [All Lists]

Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)

2006-07-11 08:40:26

On Tue Jul 11 12:27:08 2006, Kjetil Torgrim Homme wrote:

On Mon, 2006-07-10 at 00:02 +0200, Arnt Gulbrandsen wrote:
> Alexey Melnikov writes:
> > 3). Arnt has requested to allow for reject+redirect to be treated as > > just reject. I am not sure I like that. Opinions?
> > My reason:
> > If an implementation takes some trouble (e.g. using the postfix content > filter interface), it can evaluate some clauses of a sieve script based > only on the information in MAIL FROM and/or RCPT TO. After RCPT TO, > such an implementation may know that one clause in the script directs > the interpreter to reject the message, but it does not know whether > other actions are to be run, because other tests cannot yet be > evaluated.
> As I read the current draft, such an interpreter is not allowed to > reject the RCPT TO command, because it does not yet know whether the > script is valid: The script may also try to execute some action which > is incompatible with reject.

I don't think this is needed.

You may recall that I do not, and have never, implemented Sieve. I'm just an ex-sysadmin with a ManageSieve client implementation and a handful of Sieve scripts I use a lot, so you can feel a little justified in disagreeing with me, given that I merely keep half an eye on the discussion, and I admit to not reading the drafts much.

But I think this is really needed.

Otherwise, you're telling users to write their Sieve filters in a manner which is beneficial for optimization on the server. This ain't gonna happen, as they say.

Basically, if a sysadmin wants to reject the maximal amount of messages before accepting the DATA - this being a sensible and desirable thing to do - Arnt's suggestion allows the sysadmin to select an implementation and/or suitable options which allows this to happen, in the case where the user or sieve generator has chosen to reject the message. All the tweaks required to change the server behaviour are purely on the server-side. And you argue in another message that rejection at RCPT stage is more likely to stop spammers, too, so I'm sure you agree that this is the desirable state.

Your suggestion means that for best performance, a very careful choice of Sieve generator and server implementation is required. Bear in mind that one of the more common Sieve generators is the user - I know plenty of sysadmins who'd argue for more choice in their users, but I can't see this happening. Whilst your proposal is certainly bending the rules less, I don't think it's providing any benefit aside from purism.

To put it another way, I'm perfectly happy for some actions to have an implicit stop as a side-effect. In fact, until I skimmed this thread, I sort of assumed that reject *did* have an implicit stop - maybe it just sounds like a final decision.

Dave Cridland - mailto:dave(_at_)cridland(_dot_)net - 
 - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

<Prev in Thread] Current Thread [Next in Thread>