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

Re: Sieve extensions

1998-01-15 22:08:24
From: "Stan Bailes" <stan(_at_)quadcap(_dot_)com>
Date: Thu, 15 Jan 1998 16:05:52 -0800

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.

Hmm.  Yes, this is a real problem.  I don't suppose you'd prefer
that unknown extensions return 'true' instead of 'false', right?

No, I'd prefer that they return an error and leave the user's mail
unprocessed.  They're essentially link errors and can be detected just
after you finish parsing the script.

How about this:  define a 'support()' test,

That'd be section 5.8 in the draft.

I would still argue that the behavior of trying to execute an
unknown extension should be as I've proposed, though.

I strongly disagree.  This will result in unpredictable scripts.  Every
**typo** is processed as an unrecognized extension.

[re: the mystery math extension]

But that is really pretty ugly, and I don't think we're trying
to make Sieve be Turing complete via extensions, so I don't
see this "lack" as a real drawback.

I consider ruling it out to be a serious drawback.

[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.

Yes.  I have mixed feelings about this syntax, anyway.  You certainly
could achieve the same semantics with the "simpler" syntax, e.g.,

  if larger_than 500k discard;

I consider larger_than to be less desireable, and in fact, a similar syntax
was removed in an earlier revision.

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

Well, it may be the same discussion, since this proposal would seem
to support optional arguments with no further effort...

This proposal supports varible numbers of arguments with no effort, that's
true.  I want tagged, UNIX-style flag options, or something similar.  Such
options could be used to clean up the size syntax, and could also clean up
some of the lingering worries I have with the vacation extension.

-- 
                                          Tim Showalter 
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu


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