Subject: Sieve Clarifications

From: Chris Newman <[email-masked]>
Date: Wed, 30 Apr 1997 10:14:46 -0700 (PDT)

Here's some things which I think need clarifying in the document:

Section 2.5.1.

This is a useful section.

Section 2.5.2.

Also a useful section.  Need to add comments about how to RFC 822 quoting
of addresses is dealt with.  Remember that junk like:
   <"foo"  .  "bar"@baz.biff>
is a legal RFC 822 address, but for comparison one probably wants to treat
it as <[email-masked]>

Section 2.7.

Change the last SHOULD to a MUST.  A future extension could add a
test with a side effect, and it'd be good to have it's behavior
deterministic.

Section 4.1.

Need to precisely document the format of a bounce message.  How about a
MIME multipart with the first part containing the Sieve text and the
second part being the original message/rfc822.

Section 4.2.

Text needs to be added describing the security model for "fileinto".  The
two choices for dealing with POP3 issue are:

(1) Allow the "fileinto" security model to potentially forbid filing into
any folder.

(2) Make "fileinto" optional with an extension name.

I'd rather not have "fileinto" moved to a separate document.  Sieve is
mostly useless for IMAP without it.

Section 4.3.

Need to make it clear that this is an MTA-style forward (e.g. .forward
file) rather than an MUA-style forward (e.g. "forword" button on MUA).

Section 4.5.

I definitely think vacation support is a good idea.  It's incredibly
useful functionality which many people get wrong, so it'd be really nice
to have a standard way to do it right.  Of course this requires adding a
security model for dealing with the reply-history-database.

Section 4.7.

Need to discuss security impact of "toss".  It permits users to actually
lose mail.  This means if a user leaves themselves logged in at a lab
environment a malicious user could change their script to "toss".  Might
want to discuss a security model which forbids the trivial script "toss"
and it's equivalents, and suggest that servers may wish to save tossed
messages for a few days in case it was a script error.

Section 6.

Last sentence contradicts the existance of "toss".

Section 7.

I dislike the suggestion to use version numbers in extension names.
Simply say that if the extension's functionality changes, it MUST use a
different name.

---

From: Tim Showalter <[email-masked]>
Date: Wed, 30 Apr 1997 16:18:09 -0400 (EDT)

> is a legal RFC 822 address, but for comparison one probably wants to treat

I'm not sure about this.  While a comparison in addresses should make them
the same, a comparision of From headers might treat them differently.  In
the document as it stands, there are no direct comparisons of addresses.  At
least, I didn't intend any.

> test with a side effect, and it'd be good to have it's behavior

Ok.

> second part being the original message/rfc822.

That's probably the right thing to do.  If anyone wants to suggest precise
language, I'll add it; otherwise, I'll go chasing references before the next
draft goes out.

> Section 4.2.
[...]
> mostly useless for IMAP without it.

It's probably most useful in POP3 cases.  I'd like to just have an extension
name.

> file) rather than an MUA-style forward (e.g. "forword" button on MUA).

Ok.

> security model for dealing with the reply-history-database.

Should this be an extension, or is it enough to fold it into the document?
The reply database is a fairly large problem.

> Section 4.7.
> 
> Need to discuss security impact of "toss".  ...

Ok.

> Last sentence contradicts the existance of "toss".

Fixed.

> Section 7.

I'll probably remove the suggestion that extensions contain version numbers.

-- 
                                           Tim Showalter [email-masked]

---

From: Chris Newman <[email-masked]>
Date: Wed, 30 Apr 1997 14:33:55 -0700 (PDT)

> least, I didn't intend any.

Sorry, I was looking at notes on my document that I wrote as I
read it.  Comparison isn't so big a deal actually. More important is the 
addresses allowed in commands like "forward".  The problem is that 822
syntax is different from 821 syntax.  It also includes a lot of 
syntactical junk that's completely unnecessary.  If we want to make this
easy for implementors, I think we should require addresses in some
canonical form.

Choice 1:

Addresses must meet both 821 and 822 quoting rules.  Specifically, it's
either <local-part@domain> or <"local-part"@domain>.  Quotes around
name-components, whitespace and embedded comments should be disallowed.

Choice 2:

Address must be in unquoted form.  This means you have just
<local-part@domain>.  To convert to quoted form, one looks for the
rightmost "@" sign and has to quote the local-part if it contains any
specials other than "." (e.g. "@" is particularly nasty in local part).

Date: Wed, 30 Apr 1997 14:33:55 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Sieve Clarifications
To: Tim Showalter <[email-masked]>
Cc: MTA Filters <[email-masked]>
Sender: [email-masked]

> least, I didn't intend any.

Sorry, I was looking at notes on my document that I wrote as I
read it.  Comparison isn't so big a deal actually. More important is the 
addresses allowed in commands like "forward".  The problem is that 822
syntax is different from 821 syntax.  It also includes a lot of 
syntactical junk that's completely unnecessary.  If we want to make this
easy for implementors, I think we should require addresses in some
canonical form.

Choice 1:

Addresses must meet both 821 and 822 quoting rules.  Specifically, it's
either <local-part@domain> or <"local-part"@domain>.  Quotes around
name-components, whitespace and embedded comments should be disallowed.

Choice 2:

Address must be in unquoted form.  This means you have just
<local-part@domain>.  To convert to quoted form, one looks for the
rightmost "@" sign and has to quote the local-part if it contains any
specials other than "." (e.g. "@" is particularly nasty in local part).

Date: Wed, 30 Apr 1997 16:18:09 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: Chris Newman <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: Sieve Clarifications
Sender: [email-masked]

Ok.

[...]

Ok.

Ok.

Fixed.

Date: Wed, 30 Apr 1997 14:08:27 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: Sieve Readability Suggestions
Beak: Is Not
Organization: cmu
Sender: [email-masked]

Chris Newman <[email-masked]> writes:
> Yes.  There should be a single canonical format for scripts so they can be
> communicated from client to server without ambiguity.

  It's an interesting idea.

  Currently, CR and LF are treated as "whitespace" - if they're
present, they're only there *solely* for readability and comment
termination.  Your viewer could rewrap the lines and comments and come
up with something you could edit on any given platform.

  Why not go further?

  For instance, should people use tabs or spaces for indentation?  Or
a combination?  Should indentation be meaningful (if you don't think
so, look at the Python addicts in the CS community - I think they're
wrong, but they have some good points)?

  Maybe we should have one true indentation style - one tab per level,
no spaces.  Let the editor set tab stops where it wants...

  How about line length limits?  If we really want scripts to be
editable by all sorts of non-specialized editors, maybe we should
suggest (or impose) an 80-column limit on lines...

  Just some ideas - I'm far from wedded to any of these, but I think
they make about as much sense as requiring that lines end with CRLFs.

  (I'd argue that if we *really* want a single canonical format, we
should think about what a abstract syntax tree for a program in this
language should look like, write up the canonical way of encoding
those trees as text, and require that all programs be in that form
when returned from the server (since we're worried about
interchangeability, servers should be strict in what they send and
forgiving in what they accept, right?  Or should it be strict on both
ends?).  Permitting things like "one or more spaces" inbetween tokens
hardly leads to a single canonical form... (interestingly enough, the
grammar currently says that WSP is exactly one whitespace; I suspect
this will be changed :-) )

  )Rob

Date: Wed, 30 Apr 1997 13:57:30 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Rob Earhart <[email-masked]>, [email-masked]
Subject: Re: Sieve Readability Suggestions
Sender: [email-masked]

On Wed, 30 Apr 1997, Chris Newman wrote:

> On Wed, 30 Apr 1997, Rob Earhart wrote:
> > Chris Newman <[email-masked]> writes:
> > > The grammar seems to require a trailing ";" after every command
> > > (including an endif).  I'm starting to think it would be better to simply
> > > have CRLF terminate a command as many of your examples do (and use "\"
> > > CRLF to fold a line).
> > 
> >   Do we really want to impose any particular line terminator on
> > scripts?
> 
> Yes.  There should be a single canonical format for scripts so they can be
> communicated from client to server without ambiguity.

Hey, Rob, did you mean the CR/LF/CRLF thing, or are you worried about how
the script is encoded?

Date: Wed, 30 Apr 1997 10:32:40 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Sieve Readability Suggestions
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Wed, 30 Apr 1997, Rob Earhart wrote:
> Chris Newman <[email-masked]> writes:
> > The grammar seems to require a trailing ";" after every command
> > (including an endif).  I'm starting to think it would be better to simply
> > have CRLF terminate a command as many of your examples do (and use "\"
> > CRLF to fold a line).
> 
>   Do we really want to impose any particular line terminator on
> scripts?

Yes.  There should be a single canonical format for scripts so they can be
communicated from client to server without ambiguity.

Date: Wed, 30 Apr 1997 13:19:44 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: Sieve Readability Suggestions
Beak: Is Not
Organization: cmu
Sender: [email-masked]

Chris Newman <[email-masked]> writes:
> (4) Trailing ";"
> 
> The grammar seems to require a trailing ";" after every command
> (including an endif).  I'm starting to think it would be better to simply
> have CRLF terminate a command as many of your examples do (and use "\"
> CRLF to fold a line).

  Do we really want to impose any particular line terminator on
scripts?

  )Rob

Date: Wed, 30 Apr 1997 13:18:06 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: Sieve Readability Suggestions
Beak: Is
Organization: cmu
Sender: [email-masked]

Ned Freed <[email-masked]> writes:
> I finally figured out why I dislike the use of SMTP-style message text: It is
> because it makes the grammar context-sensitive: "message" (or "text:") has to
> kick the lexer into a special state. I think this is fairly problematic
> behavior at best. What happens when we want to extend the language by adding
> some other construct that requires message text as an argument.

  The grammar's still regular - when the lexer sees a "message" or
"text:" token, it switches states until it sees the end of the
SMTP-style message text; this is well within the capabilities of a
DFA.

  (By the same argument, you're against "'s, yes?  Because when a
lexer sees a " mark, it must enter a special state in which characters
are processed until a closing unescaped "... this is really no
different.)

> I think we really need to bite the bullet here and go back to some sort of
> consistent quoting scheme. I'd recommend using C style string constants,
> possibly with the extension of alloing a string to cross line boundaries.

  The problem with multiline strings is that either you wind up with
lots of backslashes at the ends of lines (which're a pain to keep
consistant when one reworks one's linebreaks), or you create a
situation in which there really isn't anything to keep a dropped
end-of-string character from causing your string to chew up far more
data than it really should, causing syntax errors far removed from the
source of the problem.

  I don't think we want lots of backslashes, and I think that a . on a
line by itself stands out much better than a " marks; much as I hate
special casing lexers, I think it's better to have two ways to quote
strings.

  (OTOH, with any non-backslash mechanism, you run the risk that it'll
still parse, potentially mailing pieces of your script and automated
responses to people who really shouldn't see it...)

  )Rob

Date: Wed, 30 Apr 1997 10:14:46 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Sieve Clarifications
To: MTA Filters <[email-masked]>
Sender: [email-masked]

Section 2.5.1.

Section 2.5.2.

Section 2.7.

Section 4.1.

Section 4.2.

Section 4.3.

Section 4.5.

Section 4.7.

Section 6.

Section 7.

Date: Wed, 30 Apr 1997 09:54:08 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Sieve Internationalization
To: MTA Filters <[email-masked]>
Sender: [email-masked]

You're going to hate me for this, but IETF standards have to deal with
this issue.

Suggestions:

(1) Sieve scripts use UTF-8 [RFC-2044].  This may require some text for
message bodies (either all Sieve messages are US-ASCII/UTF-8 or
non-UTF-8 Sieve messages have to be quoted-printable or base64 encoded).

(2) Use the concept of "comparators" (formerly ordering functions) from
ACAP (can even use ACAP's registry).

Define match-keyword as:

match-keyword = ("contains" / "matches" / "is") ["-" comparator]

I'd be tempted to make the default comparator be "en-nocase" for reasons
I've previously stated, although I'd live with "octet" as the default.

Note that ACAP's registry will require comparator registrations to state
if they're suitable for substring matching (some comparators would only
work with "is").

Finally, comparators would have extension names of "comparator-<name>".

(3) Require Sieve implementations to map MIME header encodings to utf-8.
This is probably the only way to reasonably do international searching.
Tim, you should be able to use code from the Cyrus IMAP server for this.

(4) Language tagging probably isn't necessary in Sieve itself since it
doesn't display strings.  Probably need a way to include a
"Content-Language" header in reply messages, however.

Date: Wed, 30 Apr 1997 09:20:44 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Sieve Readability Suggestions
To: MTA Filters <[email-masked]>
Sender: [email-masked]

On Tue, 29 Apr 1997, Ned Freed wrote:
> "--" becomes problematic the minute you add arithmetic operators to the
> language. Let's not make Ada's mistake here, OK?

Given this point, I withdraw the suggestion.

Date: Wed, 30 Apr 1997 08:42:14 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve Readability Suggestions
To: Tim Showalter <[email-masked]>
Cc: Ned Freed <[email-masked]>, MTA Filters <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

> I agree with this; it'll make indentation prettier, but I can see it as
> being a problem.  I opted for SMTP strings in part because mail and some
> similar programs cope with them; while this is an awkward solution, it makes
> the parser easier.  But if the theory is that novices won't write many
> scripts, I can cope with C-style strings.  (The "reply" feature is one
> that probably should be kind of difficult to use.)  If we don't use
> backslashes above, we can use backslashes here, although I'm partial to
> ANSI C-style string composition ("this is one" " long string").

The ANSI C way seems reasonable enough to me...

However, there is an alternative if you want to keep the SMTP style stuff.
Specifically, instead of making the message send operator special, you add
a lexcical component to the language that is equivalent to a string. For
example:

blah blah blah message text The text of the message starts
after the text token and continues until an SMTP-style end of string is
seen. The entire text object is lexically equivalent to having the same
thing in quotes; it does not imply any sort of operation. Here text is being
used as an argument to the message operator.
..
blah blah blah

I would also recommend that you make the following legal:

blah blah blah message "this is a one liner" blah blah blah

This way we could add, say, a mime_message operator later on:

blah blah blah mime_message text "Content-type: image/gif
Content-transfer-encoding: base64

--base64 encoded stuff here--
..
blah blah blah

				Ned

Date: Tue, 29 Apr 1997 22:52:55 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: Ned Freed <[email-masked]>
cc: MTA Filters <[email-masked]>, Chris Newman <[email-masked]>
Subject: Re: Sieve Readability Suggestions
Sender: [email-masked]

I'm going to agree with Ned again because, uh, well, I like what's in the
draft.  I'll go with whatever consensus is, of course.

On Tue, 29 Apr 1997, Ned Freed wrote:

> > > (1) Comments
> 
> "--" becomes problematic the minute you add arithmetic operators to the
> language. Let's not make Ada's mistake here, OK?
> 
> I'm not wild about "#" but the only alternative I see is "!", which might
> interfere with future operator extensions. So "#" really seems like the best
> choice for now.

I like this argument.  of course, I never used AppleScript and spend time
writing shell scripts.

> > > The grammar seems to require a trailing ";" after every command
> > > (including an endif).  I'm starting to think it would be better to simply
> > > have CRLF terminate a command as many of your examples do (and use "\"
> > > CRLF to fold a line).
> 
> I don't like this change either -- we're making the mistake Praxis (and others)
> made here. 

I'm not familiar with Praxis.

The more I think about this change, the less I like it.

> I finally figured out why I dislike the use of SMTP-style message text: It is
> because it makes the grammar context-sensitive: "message" (or "text:") has to
> kick the lexer into a special state. I think this is fairly problematic
> behavior at best. What happens when we want to extend the language by adding
> some other construct that requires message text as an argument.
> 
> I think we really need to bite the bullet here and go back to some sort of
> consistent quoting scheme. I'd recommend using C style string constants,
> possibly with the extension of alloing a string to cross line boundaries.

I agree with this; it'll make indentation prettier, but I can see it as
being a problem.  I opted for SMTP strings in part because mail and some
similar programs cope with them; while this is an awkward solution, it makes
the parser easier.  But if the theory is that novices won't write many
scripts, I can cope with C-style strings.  (The "reply" feature is one
that probably should be kind of difficult to use.)  If we don't use
backslashes above, we can use backslashes here, although I'm partial to
ANSI C-style string composition ("this is one" " long string").

Date: Tue, 29 Apr 1997 19:18:38 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve Readability Suggestions
To: Tim Showalter <[email-masked]>
Cc: MTA Filters <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

> > (1) Comments

> > I suggest using "--" instead of "#" as the comment introducer.  "--" is
> > what Applescript uses, and is more likely to make sense to the average
> > human (rather than a programmer) IMHO.

> I can see this, but I'd like a second opinion.  It seems a little strange to
> me.

"--" becomes problematic the minute you add arithmetic operators to the
language. Let's not make Ada's mistake here, OK?

I'm not wild about "#" but the only alternative I see is "!", which might
interfere with future operator extensions. So "#" really seems like the best
choice for now.

> > The grammar seems to require a trailing ";" after every command
> > (including an endif).  I'm starting to think it would be better to simply
> > have CRLF terminate a command as many of your examples do (and use "\"
> > CRLF to fold a line).

> I'll fix the examples to reflect what's in the draft.  I'm not sure I like
> this change, but it might clean things up.  I'd like a second opinion.

I don't like this change either -- we're making the mistake Praxis (and others)
made here. 

> > You currently use "message" to introduce a block of text.  I'll point out
> > that this isn't really a message, as it's lacking headers.  I suggest
> > using "text:" instead of "message".

> Ok, this is an improvement.

I finally figured out why I dislike the use of SMTP-style message text: It is
because it makes the grammar context-sensitive: "message" (or "text:") has to
kick the lexer into a special state. I think this is fairly problematic
behavior at best. What happens when we want to extend the language by adding
some other construct that requires message text as an argument.

I think we really need to bite the bullet here and go back to some sort of
consistent quoting scheme. I'd recommend using C style string constants,
possibly with the extension of alloing a string to cross line boundaries.

				Ned

Date: Tue, 29 Apr 1997 18:58:50 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: onerror (was Re: some input on sieve-00)
To: Chris Newman <[email-masked]>
Cc: MTA Filters <[email-masked]>
Sender: [email-masked]

> On Mon, 28 Apr 1997, Steve Hole wrote:
> > On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter <[email-masked]>
> > wrote:
> > > Personally, I would like to see an 'onerror' command that would allow you
> > > to try and trap an error.  This was actually a nice feature on one of
> > > the basics I used in grade school many years ago, as there were some cases
> > > where it came in useful.
> >
> > Sounds like a good idea.

> I'm opposed to an "onerror" command in the base spec.  It's very complex
> and adds very little functionality.

I agree. If "onerror" is to be added there has to be a class of errors
which are:

(1) Aren't purely syntax-related. (You cannot tell what an onerror command is
    supposed to do in the presence of syntax errors.)

(2) Are the result of some anomalous runtime condition. (Anything else should
    have been caught sooner, preferably at the time the rules were submitted.)

(3) Are something something you actually want users to be able to handle.
    (Something like a "cannot submit message because no disk space is
    available" isn't something I want users to be able to catch -- I want to
    deal with it myself.)

I believe that the class of errors that meet all three of these criteria is
empty in the language defined thus far. If anyone has a counterexample I'd
like to hear what it is.

				Ned

Date: Tue, 29 Apr 1997 14:54:10 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: onerror (was Re: some input on sieve-00)
To: MTA Filters <[email-masked]>
Sender: [email-masked]

On Mon, 28 Apr 1997, Steve Hole wrote:
> On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter <[email-masked]> 
> wrote:
> > Personally, I would like to see an 'onerror' command that would allow you
> > to try and trap an error.  This was actually a nice feature on one of
> > the basics I used in grade school many years ago, as there were some cases
> > where it came in useful.  
> 
> Sounds like a good idea.

I'm opposed to an "onerror" command in the base spec.  It's very complex
and adds very little functionality.

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: some input on sieve-00
Date: Mon, 28 Apr 1997 17:43:41 -0600 (MDT)
Sender: [email-masked]

On Sun, 27 Apr 1997 20:59:36 -0700 (PDT) Ned Freed 
<[email-masked]> wrote:

> > 6. Errors in Processing a Script
> 
> > The stipulation that implementations SHOULD NOT try to recover from a
> > script with errors is a problem for me.  Aborting within an 'if' clause
> > makes sense to me, but to totally stop filtering if any error is encountered
> > is the wrong thing to do.  I would venture a guess that most users would
> > consider this a very bad characteristic of the mechanism.
> 
> The problem with tring to recover is that you cannot be sure of what the user
> meant and you may end up doing the wrong thing. And in this case the wrong
> thing may mean losing mail.
> 
> However, as a purely practical matter I think this is largely a moot point,
> since I expect most implementations to perform syntax checking at the point 
> where rules are added. I know my implementation will do this.

Exactly.   Remember that in the worst case scenario, mail gets delivered 
to the user's inbox.

Cheers.
---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: Jack De Winter <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: some input on sieve-00
Date: Mon, 28 Apr 1997 17:43:37 -0600 (MDT)
Sender: [email-masked]

On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter <[email-masked]> 
wrote:

> >6. Errors in Processing a Script
> >
> >The stipulation that implementations SHOULD NOT try to recover from a
> >script with errors is a problem for me.  Aborting within an 'if' clause
> >makes sense to me, but to totally stop filtering if any error is encountered
> >is the wrong thing to do.  I would venture a guess that most users would
> >consider this a very bad characteristic of the mechanism.
> 
> Personally, I would like to see an 'onerror' command that would allow you
> to try and trap an error.  This was actually a nice feature on one of
> the basics I used in grade school many years ago, as there were some cases
> where it came in useful.  

Sounds like a good idea.

> >I would like to see an optimization made to the grammar.  In the elements
> >of an if-clause condition that use a list as an argument, I would like to
> >see the ability to not necessarily have the parens for single-item lists.
> >It might also be nice for users to not have to use quotes around words that
> >don't need them.
> 
> I agree on the single item lists, but not on the quotes.  The UA can
> put them in, and it makes parsing a lot simpler.

Exactly.

Wow - Jack and I agree on TWO things at once.   A truly auspicious day.  
Makes me nervous like when I write 500 lines of code and get no syntax 
errors on the first compile :-).

Cheers.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: some input on sieve-00
Date: Mon, 28 Apr 1997 17:43:34 -0600 (MDT)
Sender: [email-masked]

On 26 Apr 1997 16:34:17 -0000 [email-masked] wrote:

> On the readability front,
> 
> I would like to see an optimization made to the grammar.  In the elements
> of an if-clause condition that use a list as an argument, I would like to
> see the ability to not necessarily have the parens for single-item lists.
> It might also be nice for users to not have to use quotes around words that
> don't need them.

We don't want to get too crazy on the readability front.   In practise, a 
GUI rule builder will be the interface for novice users wanting simple 
things and advanced users will just directly edit the language.

We want to keep this thing parseable.   The parens stripping I can live 
with because that is all semantic analysis anyway, but stripping the 
quotes means two different token types and doubling of the parser trees.  
Let's not do that.

Cheers.
---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

Date: Mon, 28 Apr 1997 01:53:15 -0400 (EDT)
From: Tim Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: [email-masked], Jack De Winter <[email-masked]>, MTA Filters <[email-masked]>
Subject: Re: some input on sieve-00
Sender: [email-masked]

I agree with Ned completely, but want to add some things.

On 26 Apr 1997 [email-masked] wrote:

> 1. Introduction
> 
> The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking
> about sorting mailboxes.  Maybe something like 'autofile' or something.
> Not a big point, just a comment.

I won't change the word "sort" to "autofile" as I find that to be worse, but
I think the section might be a little vague.  Can someone give me a wrong
interpretation of the section?  Or is it better to change "sort" to
"filter"?

> 2.7 Evaluation
> 
> The second paragraph mentions the possibility that implementations may
> impose restrictions on the number of actions per message.
> 
> I think this is a bad thing. [...]

Implementations are free to disallow the limits, but I want those limits.
We have too many creative users.

> With a restriction like this, the sieve becomes significantly less useful
> for many of the users that are most likely to use it the first place -
> users adept at email.

Can you give an example?  Mailing lists and bizarre autoresponders are best
handled on private machines or by administrators.  If sites need things like
this, and can trust their users, they should turn the limits off.  However,
in order for this to be useful here, or for an ISP, there must be some way
to keep users from writing instant automated mailbombs.

> 6. Errors in Processing a Script
> 
> The stipulation that implementations SHOULD NOT try to recover from a
> script with errors is a problem for me.  Aborting within an 'if' clause
> makes sense to me, but to totally stop filtering if any error is encountered
> is the wrong thing to do.  I would venture a guess that most users would
> consider this a very bad characteristic of the mechanism.

Can you offer a counterproposal?  I can't see another good way to do it; the
syntax errors falling through cause too many problems.  Furthermore, the
design of the language allows one if clause to stop processing; aborting out
of that if clause to allow the rest of the script to run would make it
very difficult to predict control flow during a syntax error.

> I would like to see an optimization made to the grammar.  In the elements
> of an if-clause condition that use a list as an argument, I would like to
> see the ability to not necessarily have the parens for single-item lists.

Sure, this has come up before, but I haven't updated the draft.

> It might also be nice for users to not have to use quotes around words that
> don't need them.

This could cause serious ambiguity problems.  I don't think it's worth it,
especially since novice users probably won't edit scripts by hand.

As far as the errorsto-like trap, I'm against it.  For transitory failures
(which should be addressed in the draft) it's hard to imagine one that can't
be dealt with in some reasonable way (user over quota, hold the message;
some host is down that we need to talk to, hold the reply; etc.)  Everything
else is syntax errors, and as I've said before, I think it's really
dangerous to try and do something smart in case of an error.  it'll only
cause problems when the program goes and does something stupid anyway.

Date: Sun, 27 Apr 1997 20:59:36 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: some input on sieve-00
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> 0.2 - Open Issues.

> I'm curious why "fileinto" is being considered for moving into a separate
> document.  Maybe I missed an earlier thread on this.

"fileinto" needs to be a separate, optional facility becase many
implementations will not be able to support it. It also isn't something that's
going to be at all easy to write a security analysis of (something the IETF has
gotten a lot pickier about lately).

> 2.7 Evaluation

> The second paragraph mentions the possibility that implementations may
> impose restrictions on the number of actions per message.

> I think this is a bad thing.  While I understand that one of the design
> goals is to reduce the possibility of using the mechanism for mail-bombing,
> I want to point out that there is sufficient existing practice to allow
> such actions as auto-filing in conjunction with auto-forwarding.

Like it or not, this is going to have to be allowed. ISPs are not going to be
willing to deploy something that cannot impose such limits.

> With a restriction like this, the sieve becomes significantly less useful
> for many of the users that are most likely to use it the first place -
> users adept at email.

The entire point of this exercise isn't to develop something for users adept at
email. There are dozens if not hundreds of languages already available for this
purpose -- I wrote one and released it into the public domain back in 1984, and
my work was based on on the documentation of similar systems that had been
around for years.

The point here is to develop something that every MTA and message store will
want to implement and that can easily be used by various automatic rule
generation utilities. This means that the language cannot require the presence
of constructs that are difficult or impossible for everyone to implement, nor
can it require that limits obviously needed to combat spam cannot exist.

> 6. Errors in Processing a Script

> The stipulation that implementations SHOULD NOT try to recover from a
> script with errors is a problem for me.  Aborting within an 'if' clause
> makes sense to me, but to totally stop filtering if any error is encountered
> is the wrong thing to do.  I would venture a guess that most users would
> consider this a very bad characteristic of the mechanism.

The problem with tring to recover is that you cannot be sure of what the user
meant and you may end up doing the wrong thing. And in this case the wrong
thing may mean losing mail.

However, as a purely practical matter I think this is largely a moot point,
since I expect most implementations to perform syntax checking at the point 
where rules are added. I know my implementation will do this.

> On the readability front,

> I would like to see an optimization made to the grammar.  In the elements
> of an if-clause condition that use a list as an argument, I would like to
> see the ability to not necessarily have the parens for single-item lists.

I don't have a problem with this.

> It might also be nice for users to not have to use quotes around words that
> don't need them.

This is highly problematic, for the simple reason that it may have a very
adverse effect on future extensibility. The ability to distinguish between a
string argument and, say, a function that returns a string, is crucial if we
want to keep the parser implementable with single-token lookahead and the
language backwards-compatible.

> Here's an abbreviated version of the example in 2.5 to illustrate:
>   if any-of (header ("from")
>                     contains ("bart" "homer" "smithers" "burns" "lisa"),
>              header ("subject") contains ("URGENT")) then
>      fileinto "INBOX"
>   endif
> Elimitating spurious parens:
>   if any-of (header "from"
>                     contains ("bart" "homer" "smithers" "burns" "lisa"),
>              header "subject" contains "URGENT") then
>      fileinto "INBOX"
>   endif
> Eliminating sprurious quotes:
>   if any-of (header from contains (bart, homer, smithers, burns, lisa),
>              header subject contains URGENT) then
>      fileinto INBOX
>   endif

And what happens if I want to add a function bart to the language?

> The rule for whether or not quotes were needed would be based on avoidance
> of conflicts in the grammer (eg: whitespace and commas).

> I think this behaviour is more novice-friendly.

I disagree that this is more novice-friendly. What this does is introduce
an inconsistency into the language, and inconsistencies are the single
worst enemy of anyone unfamliar with the language.

It is instructive to look at past language designs in this regard. In the
Praxis language (and to a lesser extent Pascal), for example, the use of
semicolons to delimit statements was deemed to be unfriendly to novices. But
they couldn't be eliminated entirely. The resulting rules for when they were
needed and when they weren't were so complex that nobody could figure them out,
and were found to be a serious hindrance to learning and using the language.
Eventually the optionality of semicolons was effectively abandoned by
language users.

But again this is largely moot. This language design from the outset is focused
on ease of use by generating utilities, not on ease of use by novices. If
it were engineered primarily for direct use by novices it would need to
change in some fairly substantial ways from what we have now.

				Ned

Date: Sat, 26 Apr 1997 13:20:36 -0400
To: [email-masked], [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: some input on sieve-00
Sender: [email-masked]

>6. Errors in Processing a Script
>
>The stipulation that implementations SHOULD NOT try to recover from a
>script with errors is a problem for me.  Aborting within an 'if' clause
>makes sense to me, but to totally stop filtering if any error is encountered
>is the wrong thing to do.  I would venture a guess that most users would
>consider this a very bad characteristic of the mechanism.

Personally, I would like to see an 'onerror' command that would allow you
to try and trap an error.  This was actually a nice feature on one of
the basics I used in grade school many years ago, as there were some cases
where it came in useful.  

>I would like to see an optimization made to the grammar.  In the elements
>of an if-clause condition that use a list as an argument, I would like to
>see the ability to not necessarily have the parens for single-item lists.
>It might also be nice for users to not have to use quotes around words that
>don't need them.

I agree on the single item lists, but not on the quotes.  The UA can
put them in, and it makes parsing a lot simpler.

>Here's an abbreviated version of the example in 2.5 to illustrate:
>  if any-of (header ("from")
>                    contains ("bart" "homer" "smithers" "burns" "lisa"),
>             header ("subject") contains ("URGENT")) then
>     fileinto "INBOX"
>  endif
>Elimitating spurious parens:
>  if any-of (header "from"
>                    contains ("bart" "homer" "smithers" "burns" "lisa"),
>             header "subject" contains "URGENT") then
>     fileinto "INBOX"
>  endif

This makes some sense to me, as the lexical meaning is still unambiguous.

>Eliminating sprurious quotes:
>  if any-of (header from contains (bart, homer, smithers, burns, lisa),
>             header subject contains URGENT) then
>     fileinto INBOX
>  endif
>The rule for whether or not quotes were needed would be based on avoidance
>of conflicts in the grammer (eg: whitespace and commas).
>
>I think this behaviour is more novice-friendly.

While it is novice friendly, the parsing becomes more complicated.
While it might be argued that the implementor can afford to get
complicated, I would rather see the quotes around the strings stay
there, as when I read the script without quotes, it is not immediately
obvious what the strings are and what the verbs are.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

From: [email-masked]
Date: 26 Apr 1997 16:34:17 -0000
To: [email-masked]
Subject: some input on sieve-00
Sender: [email-masked]

0.2 - Open Issues.

I'm curious why "fileinto" is being considered for moving into a separate
document.  Maybe I missed an earlier thread on this.

1. Introduction

The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking
about sorting mailboxes.  Maybe something like 'autofile' or something.
Not a big point, just a comment.

2.5.1 Headers
2.5.2 Addresses

There are notes that asks whether these sections is necessary or useful.
I think they are.

2.7 Evaluation

The second paragraph mentions the possibility that implementations may
impose restrictions on the number of actions per message.

I think this is a bad thing.  While I understand that one of the design
goals is to reduce the possibility of using the mechanism for mail-bombing,
I want to point out that there is sufficient existing practice to allow
such actions as auto-filing in conjunction with auto-forwarding.

With a restriction like this, the sieve becomes significantly less useful
for many of the users that are most likely to use it the first place -
users adept at email.

6. Errors in Processing a Script

The stipulation that implementations SHOULD NOT try to recover from a
script with errors is a problem for me.  Aborting within an 'if' clause
makes sense to me, but to totally stop filtering if any error is encountered
is the wrong thing to do.  I would venture a guess that most users would
consider this a very bad characteristic of the mechanism.

On the readability front,

I would like to see an optimization made to the grammar.  In the elements
of an if-clause condition that use a list as an argument, I would like to
see the ability to not necessarily have the parens for single-item lists.
It might also be nice for users to not have to use quotes around words that
don't need them.

Here's an abbreviated version of the example in 2.5 to illustrate:
  if any-of (header ("from")
                    contains ("bart" "homer" "smithers" "burns" "lisa"),
             header ("subject") contains ("URGENT")) then
     fileinto "INBOX"
  endif
Elimitating spurious parens:
  if any-of (header "from"
                    contains ("bart" "homer" "smithers" "burns" "lisa"),
             header "subject" contains "URGENT") then
     fileinto "INBOX"
  endif
Eliminating sprurious quotes:
  if any-of (header from contains (bart, homer, smithers, burns, lisa),
             header subject contains URGENT) then
     fileinto INBOX
  endif
The rule for whether or not quotes were needed would be based on avoidance
of conflicts in the grammer (eg: whitespace and commas).

I think this behaviour is more novice-friendly.
-- 
thx,
kjj

From: [email-masked]
Date: 26 Apr 1997 15:54:55 -0000
Subject: Re: Sieve Readability Suggestions
To: [email-masked]
Sender: [email-masked]

David L Miller <[email-masked]> writes:
>On Fri, 25 Apr 1997, Tim Showalter wrote:
>> On Fri, 25 Apr 1997, Chris Newman wrote:
>> 
>> > (1) Comments
>> > 
>> > I suggest using "--" instead of "#" as the comment introducer.  "--" is
>> > what Applescript uses, and is more likely to make sense to the average
>> > human (rather than a programmer) IMHO.

Only to those familier with applescript.

>> I can see this, but I'd like a second opinion.  It seems a little strange
>> to me.

>Both are used in other languages, so there is a precedent for either
>one.  I can see the argument for matching AppleScript, since there are
>some otherwise novice potential users already familiar with it.  Do
>any other languages targeted to novices use "#"?

I'm not sure worrying about the familiarity of '#' to novices is a big
deal.  It's short and to the point and it's in wide use on at least one
platform (:-).  For users that are 'pathologically-novice' a GUI interface
is more in order anyway.
-- 
thx,
kjj

Date: Fri, 25 Apr 1997 16:23:15 -0700 (PDT)
From: "David L. Miller" <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: MTA Filters <[email-masked]>, Chris Newman <[email-masked]>
Subject: Re: Sieve Readability Suggestions
Sender: [email-masked]

On Fri, 25 Apr 1997, Tim Showalter wrote:

> On Fri, 25 Apr 1997, Chris Newman wrote:
> 
> > (1) Comments
> > 
> > I suggest using "--" instead of "#" as the comment introducer.  "--" is
> > what Applescript uses, and is more likely to make sense to the average
> > human (rather than a programmer) IMHO.
> 
> I can see this, but I'd like a second opinion.  It seems a little strange to
> me.

Both are used in other languages, so there is a precedent for either
one.  I can see the argument for matching AppleScript, since there are
some otherwise novice potential users already familiar with it.  Do
any other languages targeted to novices use "#"?

> > (4) Trailing ";"
> > 
> > The grammar seems to require a trailing ";" after every command
> > (including an endif).  I'm starting to think it would be better to simply
> > have CRLF terminate a command as many of your examples do (and use "\"
> > CRLF to fold a line).
> 
> I'll fix the examples to reflect what's in the draft.  I'm not sure I like
> this change, but it might clean things up.  I'd like a second opinion.
> 
> I would drop ; from the grammar entirely if this is the case, i.e., no more
> than one command on a line.

Single command/line is fine with me.  I don't think multiple
commands/line serve any particularly useful purpose in sieve... 

--DLM

Date: Fri, 25 Apr 1997 15:42:25 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
cc: Chris Newman <[email-masked]>
Subject: Re: Sieve Readability Suggestions
Sender: [email-masked]

On Fri, 25 Apr 1997, Chris Newman wrote:

> (1) Comments
> 
> I suggest using "--" instead of "#" as the comment introducer.  "--" is
> what Applescript uses, and is more likely to make sense to the average
> human (rather than a programmer) IMHO.

I can see this, but I'd like a second opinion.  It seems a little strange to
me.

> (2) The "header" test
> 
> I'd like it if the <header-name-list> and the <key-list> items could be
> either a list or a single quoted string.  Thus you would get:
> 
> if header "Subject" contains "$$" then
>     toss
> endif

This is probably a good idea.

> (3) The "header" -nocase arguments
> 
> I think nocase should be the default with -case as the modifier.  So you'd
> get "contains", "is", "matches", "contains-case", "is-case",
> "matches-case".  This makes it more readable, IMHO, and makes the
> more common case easier to type.

Ok, this makes sense.
 
> (4) Trailing ";"
> 
> The grammar seems to require a trailing ";" after every command
> (including an endif).  I'm starting to think it would be better to simply
> have CRLF terminate a command as many of your examples do (and use "\"
> CRLF to fold a line).

I'll fix the examples to reflect what's in the draft.  I'm not sure I like
this change, but it might clean things up.  I'd like a second opinion.

I would drop ; from the grammar entirely if this is the case, i.e., no more
than one command on a line.

> (5) Optional ","
> 
> I'm uncomfortable with "," being optional in any-of and all-of lists.  I
> think it should either be required or unnecessary.

It should be required; I'll make sure the next draft reflects this.

> (6) Normal action
> 
> How about calling this "keep"?

Fine with me.

> (7) Message introducer
> 
> You currently use "message" to introduce a block of text.  I'll point out
> that this isn't really a message, as it's lacking headers.  I suggest
> using "text:" instead of "message".

Ok, this is an improvement.

Date: Fri, 25 Apr 1997 11:16:32 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Sieve Readability Suggestions
To: MTA Filters <[email-masked]>
Sender: [email-masked]

I finally made time to read the sieve document carefully.  In general, I
think the language is in good shape.  I've got a few suggestions which I
think may improve sieve's human readability without changing the
complexity of parsing much. It's not bad as it is, but these might make it
slightly better.

(1) Comments

I suggest using "--" instead of "#" as the comment introducer.  "--" is
what Applescript uses, and is more likely to make sense to the average
human (rather than a programmer) IMHO.

(2) The "header" test

I'd like it if the <header-name-list> and the <key-list> items could be
either a list or a single quoted string.  Thus you would get:

if header "Subject" contains "$$" then
    toss
endif

or

if header ("Subject" "From") contains "B1FF" then
    toss
endif

(3) The "header" -nocase arguments

I think nocase should be the default with -case as the modifier.  So you'd
get "contains", "is", "matches", "contains-case", "is-case",
"matches-case".  This makes it more readable, IMHO, and makes the
more common case easier to type.

(4) Trailing ";"

The grammar seems to require a trailing ";" after every command
(including an endif).  I'm starting to think it would be better to simply
have CRLF terminate a command as many of your examples do (and use "\"
CRLF to fold a line).

(5) Optional ","

I'm uncomfortable with "," being optional in any-of and all-of lists.  I
think it should either be required or unnecessary.

(6) Normal action

How about calling this "keep"?

if size under 1M then
    keep
else
    toss
endif

(7) Message introducer

You currently use "message" to introduce a block of text.  I'll point out
that this isn't really a message, as it's lacking headers.  I suggest
using "text:" instead of "message".

               reply text:
               You are not one of the people I regularly correspond with.
               I have deleted your message due to the large volume of
               email I regularly receive.  If you feel that you need to
               speak with me directly, and cannot find your answer in my
               web pages, please send mail with the word "URGENT" in the
               subject line.  Thank you for your time.
               .
               endif

Date: Tue, 22 Apr 1997 16:16:38 -0400 (EDT)
From: Timothy J Showalter <[email-masked]>
To: [email-masked]
Subject: Fwd: I-D ACTION:draft-showalter-sieve-00.txt
Organization: Komitet Gosudarstvennoi Bezopaznosti
Sender: [email-masked]

The sieve draft I posted (except for some really trivial changes) has gone
out as an Internet-Draft.

---------- Forwarded message begins here ----------

Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [email-masked]
Sender: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-showalter-sieve-00.txt
Date: Mon, 21 Apr 1997 09:42:37 -0400
X-Orig-Sender: [email-masked]
Message-ID:  <[email-masked]>

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.                                                              

       Title     : SIEVE: A Mail Filtering Language                        
       Author(s) : T. Showalter
       Filename  : draft-showalter-sieve-00.txt
       Pages     : 19
       Date      : 04/18/1997

This document describes a mail filtering language for filtering messages at
time of final delivery.  It is designed to be independent of protocol, and 
implementable on either a mail client or mail server which uses multiple 
folders.  It is meant to be extensible, simple, and independent of access 
protocol, mail architecture, and operating systems used to implement it.   

Mail filtering systems are widely used for a variety of reasons, including 
organization of messages (filtering out mailing list messages for separate 
reading).  They are becoming increasingly useful in avoiding unsolicited 
mail.  Existing languages are not consistant across client, server, or 
operating system, and are frequently difficult for users to use.  This 
language is not tied to any particular system or mail architecture and is 
suitable for running on a mail server where users may not be allowed to 
execute arbitrary programs, such as on black box IMAP servers.             

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-showalter-sieve-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-showalter-sieve-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-showalter-sieve-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-showalter-sieve-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 17 Apr 1997 16:52:21 -0700
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Note: Filtering BOF was *Unofficial*
Sender: [email-masked]

Sorry, I forgot to clarify that the "Filtering BOF" was unofficial.

Date: Thu, 17 Apr 1997 11:34:33 -0700
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Summary of Filtering BOF
Sender: [email-masked]

Here is my recollection of what happened at the Filtering portion of the
Submit & Filtering BOF at IETF Memphis.  This is reconstructed from memory.

FILTERING:

Discussion of Tim's draft (posted to list and copies passed around).
Consensus: good start, make minor fixups and submit as I-D.  Discussion of
extension mechanism.  Consensus: define capability string, which each
extension adds to.  How client gets string not defined in this spec.  Could
be ACAP, could be shared file, could be magic.  Question: how to write
script such that it can work on different servers, with or without
extensions.  Consensus: need dynamic test for extension supported, either
REQUIRES or IF-EXTENSION or both.  Discussion on how script gets from
client to server.  Consensus: leave for a different draft.  Could be ACAP,
could be file (.filters), could be anything.

Discussion of where filtering occurs.  Consensus: during "final delivery",
which will differ depending on implementation, but is before message goes
into mailbox.

Discussion on specific elements of draft:  IF/ENDIF vs. "{" and "}".  No
resolution; arbitrary choice.  Discussion of blocks: needed or not?  No
consensus for them.  Discussion of BOUNCE action: do we need it?  Does it
generate DSN or MSN or neither?  Does it need parameter for text to be
returned?  Call for dropping BOUNCE since we have REPLY and TRASH.
Discussion on how to specify text of REPLY.  Series of lines with
continuation character?  Length-prefixed series of bytes?  Series of lines
ending in dot by itself (standard SMTP etc.)?  Discussion of line-endings.
CR vs. LF vs. CRLF.  Consensus: add ABNF to allow any of three.  Message
text is series of lines, ending in dot on line by itself.  Question:
doesn't this make it hard for cross-platform clients, or client on one
platform reading filter rules written by client on another platform?
Answer: they have to deal with it now.

Discussion on gearing language for machine-readability or human-readability
(continuation of list thread).  Consensus: current language is pretty good
balance.

Question on complexity of script vs. ability to be handled by GUI in
client.  Answer: if more complex elements (perhaps ELSE) are not used, GUI
can read & display existing ruleset.  If GUI encounters constructs it can't
display, it can punt and open a text window.  This should be added to
document as suggestion to client implementors.

Questions on filtering on envelope contents, syntax to do INCLUDE, filing
into folders other than INBOX, and regular expressions.  Consensus:
filtering on envelope contents to be an extension.  Syntax for INCLUDE to
be in URI notation, but as an extension, not in base spec.  Filing into
folders other than INBOX, and regular expressions to be extensions.

Question on STOP.  Answer: it ends all rules.  Any actions already
specified (for example, filing, replying) get done, but no additional rules
or actions are processed.

Question on what if no actions specified/no rules matched.  Answer: default
action (file into inbox).

Date: Mon, 14 Apr 1997 21:05:10 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: sieve draft
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-1804928587-861066310=:7488
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is the latest draft of the SIEVE filtering language.  I've also dropped
a copy at http://www.club.cc.cmu.edu/~tjs/draft-showalter-sieve-00.txt.  I'm
in the process of submitting a copy as an internet-draft.

I plan to do some heavy editoral changes, but I think it's close to complete
in terms of content and features.  Rob has been bugging me to make a good
clean distinction between keywords and commands, and that should happen
before this becomes an RFC.

Any comments would be appreciated!

---559023410-1804928587-861066310=:7488
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-showalter-sieve-00.txt"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 

MjBdDQoM
---559023410-1804928587-861066310=:7488--

Date: Tue, 1 Apr 1997 22:50:43 -0500 (EST)
From: Tim Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: pre-draft for language
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-342241519-859953043=:1026
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

This is a draft for the filtering language.  I managed to fill in a few
examples, but there are still a lot of consistancy errors that arose from
making a lot of changes in the grammar.  I'm posting it anyway because I
believe it'll be better to actually let people see it.

If you find obvious errors, let me know.  I'm SURE there are places that are
not internally consistant.  I'll work on it more tomorrow.

Thanks ...

---559023410-342241519-859953043=:1026
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-showalter-sieve-00.txt"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: draft-showaltersieve-XX.txt

---559023410-342241519-859953043=:1026--