Subject: Re: Sieve extensions

From: "Stan Bailes" <[email-masked]>
Date: Tue, 20 Jan 1998 11:09:21 -0800

Matthew Wall <[email-masked]> writes:

>In general, I'd disagree with the notion that the storing or transporting
>agent (e.g. ACAP) ought to be involved with validating the code. It seems
to
>me this is killing the messenger for delivering a BAD message, as it were.
>Since generation and interpretation are the responsibility of SIEVE-aware
>agents, the error-checking should be strictly handled at those points.
>Otherwise you put some pretty severe implementation restrictions on a
>storage mechanism that probably out to be (literally) value-neutral.

But what about the case where the Filter Agent (FA) is ACAP-aware, and
exports an ACAP 'filter' dataset profile?  It certainly seems possible to
define the filter dataset so that the server can perform language-level
validation;  this is little different from profile-specific validations
performed by other ACAP dataset extensions.

Now, this *is* different from the case where the FA is an ACAP client,
in which case the store probably should be "value-neutral".  Such an
implementation would be forced to complain about script validation problems
at mail-delivery time.

Stan

---

From: "Chris Bartram" <[email-masked]>
Date: Mon, 26 Jan 1998 12:14:07 -0500

In <[email-masked]> [email-masked] writes:

> > From: "Stan Bailes" <[email-masked]>
> > Date: Mon, 26 Jan 1998 07:12:27 -0800
> >
> > Though I can see it now:  the first line of every Sieve script will be
> >
> >     require "support";
>
> I oppose require unless it's metainformation for similar reasons to my
> opposition to support.  ;-)
>
> (My basic problem is that I never want runtime errors.  A script should be
> verified at time of submission, and if it's unusable, it should be
> refused, and never run.  Require is taken out of the most recent draft to
> stop runtime errors like

Though I'm ambiguous on "support"; you're GOING to encounter runtime errors
on occasion. From our simple rules implementation:

'IF subject contains "some string" FILE trash-folder'

(Which is a pretty common use of rules - I think you'll agree) you're going
to encounter situations where the user HAD a "trash-folder" when the rule
was defined, but has since removed it. So there has to be a (simple? or at
least consistent) means of reporting such errors. With multiple-access
protocols like IMAP, it's possible that the process defining the rules
wouldn't know about the change until a rule was executed.

Obviously that's not in the same league as an error parsing the script, but
the effect is near the same. A rule (maybe a critical one) is invalid. What
do we do? Given any "rule" whose action depends on a "parameter" - like a
folder name or some other mail-system attribute that can change - there's
always the chance that when it's actually "executed" that the action is not
valid. I don't have a good solution here, though I would hope that the new
syntax would allow the script-creator some means of controlling what happens
at run-time. Ignore; stop all rule processing; send an e-mail error report
and go on; etc. Either a global setting in the script or a per-line error
handling option perhaps -- with a CLEARLY defined default behaviour.

           -Chris Bartram