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.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)jabber(_dot_)org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade