Subject: Sieve extensions

From: "Stan Bailes" <[email-masked]>
Date: Thu, 15 Jan 1998 10:27:41 -0800

I would like to see the Sieve language provide a generalized extension
syntax, which would permit a Sieve parser to
parse a file containing extensions that it didn't necessarily support.
This seems like it would maximise interoperability, and would make
future extensions easier, since their impact on existing implementations
could be more easily assessed.

I propose to add extension functionality as follows.  Basically, a
sieve extension is either a test or an action.  Both tests
and actions are functions which operate on messages.

test:  Message -> {true,false}
action:  Message -> {Continue, Stop}

The current grammar for the 'action' statement in Sieve is:

[OLD]       action = toss / fileinto / forward / bounce / reply / stop
[OLD]       toss = "toss"
[OLD]       fileinto = "fileinto" WSP string
[OLD]       forward = "forward" WSP address
[OLD]       bounce = "bounce" WSP string
[OLD]       reply  = "reply" WSP string

I would propose to replace this with:

[NEW]       action = ATOM *( [WSP] ( string / number ) )
[NEW]       ATOM = LETTER *(LETTER / DIGIT / "_" / ".")

Similarly for the 'test' clause, currently spec'ed as:

[OLD]       test = [WSP] (any-of / all-of / exists / false / header /
[OLD]              not / size) [WSP]

I would propose using:

[NEW]       test = [WSP] ATOM (string / string-list) [WSP]

And I would add a statement to the standard like this:

A Sieve implementation MUST interpret unknown extension
tests as always returning false, and unknown actions as
no-ops returning 'Continue'.

The standard could then go on to define a base set of tests and
actions (pretty much what we've got now), in terms of the
expected arguments and semantics, within this more generalized
framework.  Some kind of IANA registry could be used to keep
track of various extensions.

I could write all of this up in RFC-speak, but I thought
I'd see what people thought of the basic idea first...

Stan

---

From: Tim Showalter <[email-masked]>
Date: 15 Jan 1998 17:15:28 -0500

> From: "Stan Bailes" <[email-masked]>
> Date: Thu, 15 Jan 1998 10:27:41 -0800
> 

> no-ops returning 'Continue'.

My reasoning has to do with the inevitability of a script where users
specify some criteria for mail "to" them (say, to a known mailing list, or
to an address considered theirs) where it works out like this.

 if some-random-extension-that-i-dont-support-yet-has-critical-importance
 {
 	keep;
 } else {
	discard;
 }

A more practical and realistic example doesn't have quite the same dangers
to it.

 if header "to" contains ("[email-masked]"
			  "[email-masked]") { vacation
    vacation "Hi, I'm out, I'll get back to you sometime after April.
 "; }

where vacation isn't supported -- it's ignored, and the user who has gone
to the trouble of putting in a vacation filter sees their work go
completely to waste.

There has to be some discussion on exactly what gets changed in the grammar.

> [NEW]       ATOM = LETTER *(LETTER / DIGIT / "_" / ".")

This restricts commands to never accepting things that aren't strings or
numbers.  For instance, there's no way to incorporate this into the grammar
of this "generalized extension syntax":

	set foo = 5 + 5 ;

This also doesn't address the size command, which takes another "atom" as
an argument.

> [NEW]       test = [WSP] ATOM (string / string-list) [WSP]

The example in section 2.7 of the draft
   Example:  if size over 500K discard;
is outside of what this grammar can do.

I'm not really opposed to this, but I want to be very, very specific that
it is not a minor change, and that it doesn't buy you much outside of
making some trivial extensions (like vacation) easy.

I do want some form of optional arguments, but that's another discussion.

-- 
                                          Tim Showalter [email-masked]