On Fri, Jul 01, 2005 at 11:16:30AM -0700, Ned Freed wrote:
One thing that's bugged me about the vacation extension is that it's not
entirely self-contained, in that the database has to be attended to via
some external means.
I, OTOH, believe this to be one of the main strengths of this proposal,
and indeed of sieve in general.
Maybe you could explain more? The vacation database is entirely owned
by the delivery application, which ought to be able to completely control
that data as well, including instantiating it and validating it.
I infer from your comments (and correct me if I am wrong; I'm only
trying to understand) that you would mandate the use of helper tools in
maintaining seive scripts. That's a fine administrative perspective,
but I wouldn't want to see it as part of the language document, nor
require other administrators to think the same way. On the contrary, I
would hope that, as much as possible, the language would be designed to
simply work when correct syntax is used. I've described one problem
that the vacation extension has in this regard, and suggested a way to
address it. There may be better ways; it was just an idea.
Perhaps I'm alone in this; if so, well, that's the way it goes..
Deletion. Script author removes the vacation statement (or disables
it). Deletion of data has to be done separately. An environment can
certainly provide for this in some site-specific way. OTOH the data
doesn't have to be deleted; in practice it does no harm, and users of
other vacation mechanisms probably don't always delete their vacation
database either (until the next initialization wipes it). OTOOH,
a script writer who always uses different handles would cause old
data to pile up. Might be worth some words of warning.
I fail to see any real added risk here. Consider: Vacation can be executed at
most once per incoming message, so the maximum number of database entries the
vacation action can produce per incoming message is one. So, if the intent is
to fill up the database, the simplest way to do it is set up regular vacation
without a handle setting and send in a bunch of messages from different
sources. Note. however, that implementations are free to limit the number of
remembered responses, so this trick will only work if the implementation
allows
it.
Now suppose we add handle to the mix. It cannot be used to get past the "one
entry per message" limit - there still has to be one message sent per database
entry. Can it be used to, say, cause duplicate messages to create separate
database entries? Sure, but only if you're willing to create a vast long
script
that tests some highly variable piece of message data and switches to a
different handle on that basis. (Remember that use of vacation parameters MUST
NOT have had variables expanded prior to their use in response tracking.)
As I said, "in practice it does no harm." I was simply thinking of the
potential for little bits of data to accumulate over time, especially
with somebody who writes scripts by hand and might choose a different
handle each time. At any rate it's hardly the point of the message,
it was only a casual side remark.
Yours,
-mm-