ietf-mta-filters
[Top] [All Lists]

Re: Sieve extensions

1998-01-15 15:17:29
From: "Stan Bailes" <stan(_at_)quadcap(_dot_)com>
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.

I have no real problem with this, but I object to this:

A Sieve implementation MUST interpret unknown extension
tests as always returning false, and unknown actions as
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 ("tjs(_at_)andrew(_dot_)cmu(_dot_)edu"
                          "tjs+(_at_)andrew(_dot_)cmu(_dot_)edu") { 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.

I would propose to replace this with:

[NEW]       action = ATOM *( [WSP] ( string / number ) )
[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 
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu


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