Subject: IMAPFLAGS SIEVE extension

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Nov 1998 23:55:28 +0300

Hi,

I've recently wrote SIEVE extension that allows to set IMAP flags on
delivery. I will appreciate any feedback from the mailing list.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------

Network Working Group                                       
Internet Draft: Sieve -- IMAP flag Extension                 A. Melnikov
Document: draft-melnikov-sieve-imapflags-00.txt     Epsylon Technologies
Expires: 22 April 1999                                   22 October 1998

                      Sieve -- IMAP flag Extension

Status of this memo

   This document is an  Internet-Draft.  Internet-Drafts  are  working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are  draft  documents  valid  for  a maximum of six
   months  and  may  be  updated,  replaced,  or  obsoleted  by  other
   documents  at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite  them  other  than  as  ``work  in
   progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt''  listing  contained  in  the  Internet-Drafts
   Shadow   Directories   on   ftp.is.co.za   (Africa),  ftp.nordu.net
   (Europe),  munnari.oz.au (Pacific Rim),  ds.internic.net  (US  East
   Coast), or ftp.isi.edu (US West Coast).

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or  using  this
   protocol  are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright

   Copyright (C) The Internet Society 1998.  All Rights Reserved.

Abstract

   Recent discussions   have  shown  that  it  was  desirable  to  set
   different [IMAP] flags on message delivery.  (This can be done, for
   example, by SIEVE interpreter that works as a part of Mail Delivery
   Agent (MDA)).

   This document describes an extension to the  Sieve  mail  filtering
   language for setting [IMAP] flags.

Melnikov                   Expires April 1999                   [Page 1]

Internet Draft             Sieve -- IMAP flag Extension     October 1998

0. Meta-information on this draft

   This information  is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1. Discussion

   This draft is intended to be compared with the Sieve mail filtering
   language,  an  Internet-Draft  being  discussed  on the MTA Filters
   mailing list at <[email-masked]>.  Subscription  requests
   can  be  sent  to <[email-masked]> (send an email
   message with the word "subscribe" in the body). More information on
   the  mailing  list  along  with  a  WWW archive of back messages is
   available at <http://www.imc.org/ietf-mta-filters/>.

1. Introduction

   This is an extension to the Sieve language defined by  [SIEVE]  for
   setting [IMAP] flags. It defines new action "setflag".

   This document  doesn't dictate how SIEVE interpreter can set [IMAP]
   flags. In particular, SIEVE interpreter may work as an IMAP client,
   or may have direct access to the mailstore.

   SIEVE interpreters,  that  doesn't  support  integration  with IMAP
   SHOULD ignore this extension.

   Conventions for notations are as in [SIEVE] section 1.1,  including
   use of [KEYWORDS].

2. Capability Identifier

   Sieve implementations   that   implement  setflag  action  have  an
   identifier of "IMAPFLAGS" for use with the capability mechanism.

3. Setflag Action

   Syntax:   setflag <list-of-flags>

   Setflag is used  for  setting  [IMAP]  flags.  It  should  be  used
   together  with  keep  or fileinto.  It MUST be ignored if mailstore
   doesn't support the storing of any flags.

   Flags can be set only for message that is  currently  processed  by
   SIEVE.  When  called  with keep,  setflag sets flags in user's main
   mailbox.  When called with fileinto,  setflag  sets  flags  in  the
   mailbox, indicated by the parameter.

Melnikov                   Expires April 1999                   [Page 2]

Internet Draft             Sieve -- IMAP flag Extension     October 1998

   The order  of  setflag/fileinto or setflag/keep is not important in
   the script.  Multiple occurrences of setflag are treated  additive.
   This mean, that the following two actions

      setflag "\Deleted";
      setflag "\Answered";

   produce the same result as single action

      setflag ["\Deleted", "\Answered"];

   Server MUST ignore all flags that it can't store permanently.  This
   mean,  in  particular,  that if user's main mailbox can't store any
   flags, then the following SIEVE script produces no actions

      Example:  if size over 500K setflag "\Deleted";

   More substantial example is:

      Example:
             if header "from" contains "[email-masked]" {
               setflag "\Flagged";
               fileinto "INBOX.From Boss";
             }

4. Interaction with Other Sieve Actions

   Sieve actions sometimes  prohibit  each  other  in  order  to  make
   filtering scripts less likely to cause serious problems.

   It is  strongly  discouraged  to  use  setflag action together with
   forward,  reject and discard,  because these  actions  don't  allow
   keeping received message.

   SIEVE interpreter MUST ignore setflag command, when it is used with
   forward, reject and discard (or  similar).  SIEVE  verifier  SHOULD
   reject script, which contains setflag together with forward, reject
   and discard (or similar).

5. Other Considerations

   This extension intentionally doesn't allow setting [IMAP] flags  on
   arbitrary message in IMAP store.

6. Security Considerations

   Security considerations are discussed in the [IMAP] and [SIEVE].
   It is belived that this  extension  doesn't  introduce any
   additional security concerns.

Melnikov                   Expires April 1999                   [Page 3]

Internet Draft             Sieve -- IMAP flag Extension     October 1998

6. Formal Grammar

   The grammar used in this section is the same as the ABNF described in
   [ABNF].

   action =/ setflag         ;; "setflag" is now a legal action

   setflag = "setflag" WSP string-list
     ;; a list of [IMAP] flags

7. Author's Address

    Alexey Melnikov
    Epsylon Technologies
    121293, Russia, Moscow, 
    general Ermolov street, 6 - 90

    Email: [email-masked]

Melnikov                   Expires April 1999                   [Page 4]

Internet Draft             Sieve -- IMAP flag Extension     October 1998

Appendices

Appendix A.  References

   [ABNF] Crocker, D.,  "Augmented BNF for Syntax Specifications: ABNF",
   Internet Mail Consortium, RFC 2234, November, 1997.

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", Harvard University, RFC 2119, March 1997.

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language", Carenegie
   Mellon, Work in Progress.

   [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
   University of Washington, RFC 2060, December 1996.

Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1997. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.

Melnikov                   Expires April 1999                   [Page 5]

---

From: "Barry Leiba" <[email-masked]>
Date: Wed, 11 Nov 1998 17:08:04 -0500

> delivery. I will appreciate any feedback from the mailing list.

I'm not fond of it, mainly because it's so IMAP-specific, and the idea 
of allowing a filter to flag a message is too good to relegate to servers 
that implement their SMTP delivery agent integrated with their IMAP server 
(we do, so we could do this, but...).

I see little use for setting some of the flags, such as \Deleted and
\Draft, and other flags might be removed from the IMAP context with a 
little thought.  I'd rather see the idea put in a form that can go into 
the base document.

We could add a "flag" action, the semantics of which are just "flag this 
message in a way that makes sense to the underlying implementation."  That 
would correspond to the IMAP \Flagged flag.

I could see some value in providing a way to mark a message as "seen" from
a script.  The "flag as interesting" and "mark as seen" ideas could be
pulled away from the IMAP context, and put in as actions that must be
implemented, but may do nothing if the SMTP delivery agent can't do
anything with them.  I'm not sure how much I like that either.  I guess
I'm waffling here.

I don't think there's a way, without being IMAP-specific, to add something
that will let the user set user-defined IMAP flags (ones that don't begin
with "\").

The draft is wrong to say that "forward" doesn't allow the message to be
kept, so it's wrong to prohibit setting flags on a forwarded message.

Barry Leiba, Multimedia Messaging   ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 1998 01:42:32 +0300

> (we do, so we could do this, but...).

First of all, thank you for spending your time.

> would correspond to the IMAP \Flagged flag.

May be you are right.

> that will let the user set user-defined IMAP flags (ones that don't begin

You are right. But this is the main use of proposed draft (as it was
intended). I wanted to wrote that this draft was not intended to be used by
SIEVE interpreter that was running on client.

Some flags must be set only in the time of final delivery (for example
$MDNRequired flag for telling IMAP client that it should send Message
Disposition Notification).

Anyway I think that sometimes you should be specific. For this purpose I
wrote, that SIEVE interpreter, that knows nothing about IMAP may ignore
"setflags" action.

> kept, so it's wrong to prohibit setting flags on a forwarded message.

Ok, I will correct this.

> http://www.research.ibm.com/people/l/leiba

Regards,
Alexey Melnikov

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Thu, 12 Nov 1998 02:14:18 -0800

The following is a proposal for several new actions, and an extension to the
"forward" action.  We have customers that have expressed interest in these
features within our Sieve implementation, especially for the per-user Sieve
rules.

The extension to the "forward" action is the addtion of a ":file" argument:

    Syntax: forward <addresses>
		forward :file <file>

    It should be possible to forward to multiple addresses.  To make this
    easy, the :file <file> argument causes the contents of <file> to be
    used as a list of addresses.  Each implementation MUST support a file
    syntax of one RFC822 address per line.  Impementations MAY support
    multiple RFC822 addresses per line, separated with ";".  Implementations
    MUST support RFC822 comment syntax, including on otherwise empty lines
    of text.

Action insert

    Syntax:	insert [:new] :header <header> <text>
		insert :body <text>
		insert :body :file <file>

    The "insert" action inserts a line, or lines, of text as either a new
    header or within the body.  In either case, the "<text>" is one or
    more lines of text inserted at the front of the header or body.

    For "insert :header", if the <header> already exists within the message
    header, it is renamed as "Old-<header>", and a new header is inserted,
    with the value of <text>.

    The ":new" argument, taking no arguments itself, causes the header field
    to be inserted, without regard or affect to existing header fields of
    the same name.

    If ":file <file>" is given, then the text to insert within the body is
    obtained by reading the "<file>".

    Whether the text is obtained from a "<text>" argument, or by reading
    the lines of text from a <file> argument, each implmentation SHOULD
    support these variables within the text:

	$NAME		- the user portion of the current email address
	$HOST		- the hostname portion of the current email address
	$SENDER	- the address of the sender of the mail being filtered
	$DATE		- the original "Date:" field of the message being filtered
	$SUBJECT	- the subject string, without leading "Re:" or "FW:"
			  strings.

    Example:

	if header ["To"] :contains "ietf-mta-filters" {
		insert :header "X-Filed" "ietf"
		fileinto "Lists/IETF"
		keep
	}

    The above example will cause a new "X-Filed:" header to be inserted,
    possibly causing any existing similarly-named headers to be renamed as
    "Old-X-Filed:"

	if header ["To", "Cc"] :contains "humor" {
		insert :body "humor-leader.txt"
		resend :file humor-list
	}

    This example is of a "poor man's" mailing list.

Action append

    Syntax:	append [:new] :header <header> <text>
		append :body <text>
		append :body :file <file>

    The "append" action appends a line, or lines, of text to either a
    (possibly new) header field, or to the body.  In either case, the
    "<text>" is one or more lines of text appended at the end of the
    header or body.

    If the ":new" argument is given, then header fields are inserted
    without regard to, or affecting, an existing header field by the
    same name.

    The "append :header" action appends a header field to the header;
    if the header field already exists, it is renamed as "Old-<header>".

    The "append :body" action appends the given text to the end of
    the body.

    If ":file <file>" is given, then the text to append is obtained by
    reading the "<file>".

    For alternatives, please see the "insert" or "replace" actions.

    Examples:

	if header ["To"] :contains "ietf-mta-filters" and
	   not header ["X-Filed"] :contains "ietf" {
		append :new :header "X-Filed: ietf"
		fileinto "Lists/IETF"
		keep
	}

	# implement a personal mailing list
	if header ["To", "Cc"] :contains "humor" {
		append :body "humor-leader.txt"
		resend :file humor-list
	}

Action replace

    Syntax:	replace :header <header> <text>
		replace :body <text>
		replace :body :file <file>

    The "replace" action inserts a line, or lines, of text in either a
    header field, or the body.  In either case, the "<text>" is one or
    more lines of text used to replace an existing header field or message
    body.  In the case of ":header", if the header field does not exist,
    then it is appended at the end of the header.

    The "replace :header" action replaces an existing header named <header>
    with <text> or the contents of <file>.  If the header doesn't already
    exist, then the action is identical to "append".

    The "replace :body" action appends the given text or file contents to
    the end of the body.

    If ":file <file>" is given, then the replacement text is obtained by
    reading the "<file>".

    For alternatives, please see the "insert" or "replace" actions.

    Example:

	if header ["To"] :contains "ietf-mta-filters" and
         not header ["X-Filed"] :contains "ietf"
      {
		replace :header "X-Filed: ietf"
		resend "Local-IETF-List"
	}

Looking for comments!

--
Alan K. Stebbens <[email-masked]>

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Thu, 12 Nov 1998 10:21:55 -0800

The example under the "Action append" definition was incorrect; here is the
correct
example.

 	if allof( header ["To"] :contains "ietf-mta-filters",
 	          not header ["X-Filed"] :contains "ietf")
      {
 		append :new :header "X-Filed" "ietf"
 		fileinto "Lists/IETF"
 		keep
 	}

The example under the "Action replace" definition was also incorrect; it
should read:

 	if allof( header ["To"] :contains "ietf-mta-filters",
                not header ["X-Filed"] :contains "ietf")
      {
		if not header ["Subject"] :contains "[IETF]" {
			replace :header "Subject" "[IETF] $SUBJECT"
		}
		append :header "X-Filed" "ietf"
 		resend "Local-IETF-List"
 	}

	The above example modifies the original Subject header by inserting a list
	identifier into the subject.

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Thu, 12 Nov 1998 10:06:56 -0800

Sorry..

Here's the correct definition of "replace":

Action replace

     The "replace" action replaces a line, or lines, of text in either a

     The "replace :body" action replaces the current mail body with the
given
     text or file contents .

     For alternatives, please see the "insert" or "append" actions.

     Example:

 	if header ["To"] :contains "ietf-mta-filters" and
          not header ["X-Filed"] :contains "ietf"
      {
 		replace :header "X-Filed" "ietf"
 		resend "Local-IETF-List"
 	}

---

From: Randall Gellens <[email-masked]>
Date: Thu, 12 Nov 1998 14:52:37 -0800

I'm sorry, but I have to object.  This is way too much complexity to 
even be considered for the base spec.

I think we need to concentrate on getting a base spec that is as easy 
as possible to implement, and supports enough functionality to be 
useful.  I'm sure there are all sorts of wonderful things we could add, 
but if we try and cram them into the base spec we'll never get it done, 
and it won't get widespread support.

The Sieve effort has been going on for a couple of years now, and I 
think we need to get a minimal base spec out the door.  Personally, I'd 
be happy with the -03 one, but I think we can come to agreement on the 
-04 one.

If I've misunderstood you, and you want these to be considered as 
extensions, in their own document, that's a different matter.
--
Randall Gellens
[email-masked]
QUALCOMM Incorporated
Opinions are personal;    facts are suspect;    I speak for myself only

---

From: Randall Gellens <[email-masked]>
Date: Thu, 12 Nov 1998 14:43:57 -0800

> (we do, so we could do this, but...).

It seems to me that since we agree that fileinto is useful to have in 
the base Sieve spec (despite being unable to be executed by the server 
in a POP environment), that having setflag would also be useful.  On 
the other hand, I can think of some IMAP servers where Sieve can be 
implemented, including fileinfo, but where setflag couldn't be done, at 
least without changing the server's plug-in API.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Nov 1998 02:13:26 +0300

> least without changing the server's plug-in API.

In such a case you are free to ignore "setflags" (as a wrote in the document).

Other important issue. As Tim Showalter noticed setflags should be bind to
fileinto, because multiple fileinto are possible for the same message. Any
ideas? (Tim Showalter proposed to add additional parameter to fileinto, so I
mean "any other ideas" here)

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Thu, 12 Nov 1998 15:27:27 -0800

| I think we need to concentrate on getting a base spec that is as easy
| as possible to implement, and supports enough functionality to be
| useful. ..

| The Sieve effort has been going on for a couple of years now, and I
| think we need to get a minimal base spec out the door.  Personally, I'd
| be happy with the -03 one, but I think we can come to agreement on the
| -04 one.

This sounds like a reasonable plan.

| If I've misunderstood you, and you want these to be considered as
| extensions, in their own document, that's a different matter.

This sounds like a better approach than stopping forward progress on a
nearly drafted spec.  Is there an existing template for suggesting
extensions?

Given that, I would still like to suggest that the tests "and" and "or" be
defined in the draft spec. as synonyms, if not the primary names, for
"allof" and "anyof", respectively.  The former are almost universally
intuitively understood everywhere, whereas the latter are, let's say, unique
to this draft.

Thanks for the feedback.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 12 Nov 1998 15:51:14 -0800

> nearly drafted spec.  Is there an existing template for suggesting

The draft now says only that new extensions must define a keyword, so 
the presence of the extension can be tested.  We should add an 
extension registry mechanism to the draft, along the lines of what is 
in ACAP or perhaps POP Extensions.  That is, add an "IANA 
Considerations" section, spell out the requirements (for example, 
published in an IESG-approved experimental or standards-track RFC) and 
specify what information must be in the extension spec.  Given the fact 
that extensions could modify all sorts of Sieve behavior, we can't be 
too explicit. 

> intuitively understood everywhere, whereas the latter are, let's say, unique

This conflicts with one of the prime goals of Sieve, which is ease of 
implementation.  It was also discussed very early in Sieve development. 
Can you elaborate on why you feel the alternate syntax is required?

---

From: Randall Gellens <[email-masked]>
Date: Thu, 12 Nov 1998 15:43:38 -0800

> mean "any other ideas" here)

I think the simplest thing to do is to have setflags and fileinto be 
separate actions.  A setflags which is not followed by a fileinto sets 
flags for the message when it is filed into the default folder (inbox). 
A setflags followed by a discard means the setflags was for naught, but 
so what?

Alexey, how would you feel about pursuing setflags as an extension 
after the Sieve base spec is published?  As useful as I think setflags 
is, I think we need to focus on keeping Sieve simple and getting it out 
the door.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Nov 1998 03:05:08 +0300

> A setflags followed by a discard means the setflags was for naught, but

This is the current behaviour. The problem with multiple fileinto can be shown in
the following example:

fileinto "INBOX/TodayMail";
setflag "\Deleted";
fileinto "INBOX/FromBoss";
setflag "\Answered";

The second setflag relates to the first or second fileinto?

> is, I think we need to focus on keeping Sieve simple and getting it out

I really want SIEVE to be published as standard as soon as possible.
I don't want setflag to be added to the base spec. Do you propose to abandon
setflag until SIEVE is published as RFC?

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Thu, 12 Nov 1998 17:06:35 -0800

| > Given that, I would still like to suggest that the tests "and"
| and "or" be
| > defined in the draft spec. as synonyms, if not the primary names, for
| > "allof" and "anyof", respectively.  The former are almost universally
| > intuitively understood everywhere, whereas the latter are,
| let's say, unique
| > to this draft.
|
| This conflicts with one of the prime goals of Sieve, which is ease of
| implementation.  It was also discussed very early in Sieve development.
| Can you elaborate on why you feel the alternate syntax is required?

I have two answers: a clarification and a bit of philosohy.

To clarify:

I am suggesting that "and" and "or" be defined as infix tests, with the
intentional side-benefit of avoiding the "short-circuit" evaluation problem.
In the test expression below:

	test1 and test2

test1 would evaluate first, and only if its value is true, would test2 be
evaluated.

	test1 or test2

The "or" test would similarly function such that test2 would only be
evaluated if test1 were false.

Using infix notation improves readability (it is more natural to read), is
not difficult to parse, and provides even simple parsers the side-effect of
being easy to skip evaluations.

Now the Philosophy:

A prime goal of sendmail.cf was that it be easy to parse.  In hindsight, it
would have been better to have a more readable configuration language, even
if the computer had to work a little harder at parsing it.

Which is more important in the long run?  Human time or computer time?

Let's suppose that the real goal of Sieve is to establish a usable email
filtering standard for the Internet, one which lets users across the
Internet easily define filtering rules.  Given this supposition, is it
better that a few programmers work harder to write a good parser, or better
to have millions of Internet users work harder to write their filters in yet
another "easy to implement" but difficult to understand language?

If "easy to implement" is really the prime goal, then why not just use
"regex"?  It *already* exists, is very fast and efficient.  There are even
lots of users who are very comfortable with it.  For those users who do not
understand it, there is lots of documentation all over the Internet on its
usage.

Since "regex" wasn't used, I suspect that there must have been a sub-goal of
"easy to comprehend" by the user.

I would rather have a language that is easy to write and comprehend by
humans, even if it is a LALR(1) language that requires a bit of effort to
parse.  The parsing effort can be minimized by clever designs, such as using
good parsing technology (flex, bison), and precompiling the Sieve filters
into a byte-code (ala regcomp/regex).  This may make the implementation more
difficult, but this extra bit of work now pays big dividends later.

We don't need another sendmail.cf.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 12 Nov 1998 17:11:24 -0800

At 3:05 AM +0300 11/13/98, Alexey Melnikov wrote:

> The problem with multiple fileinto can be shown in
> the following example:
>

I think the simplest approach is also very clear.  Any setflag applies 
only to subsequent fileintos (which may be the default fileinto inbox).

> setflag until SIEVE is published as RFC?

I wouldn't say abandon.  I think it is worth continuing work on in 
parallel, but make it clear that it is an extension, both in the draft 
and in mailing list discussions.

---

From: Matthew Wall <[email-masked]>
Date: Fri, 13 Nov 1998 17:59:53 -0400

> and in mailing list discussions.

fwiw, I agree...I personally find this a really useful extension, since it
could be used by the client as well (we already have such a capability, for
instance, it would be nice to make our filter match Sieve syntax) but it's
not a base spec item.

- matt

 =====================================================================
   Matthew Wall * mailto:[email-masked] * http://www.cyrusoft.com
   Cyrusoft International, Inc.          Proud Purveyors of Mulberry
            "Making the desktop safe for IMAP since 1995"
 =====================================================================

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Nov 1998 19:10:34 -0800 (PST)

> instance, it would be nice to make our filter match Sieve syntax) but it's

I agree as well.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Nov 1998 16:29:30 +0300

> > instance, it would be nice to make our filter match Sieve syntax) but it's

I am glad to know this.

Can an extension modify (add) a list of parameters of some action?

---

From: Ned Freed <[email-masked]>
Date: Sun, 15 Nov 1998 15:22:14 -0800 (PST)

> Can an extension modify (add) a list of parameters of some action?

I don't see why not, as long as it doesn't change the underlying "core" syntax.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Nov 1998 01:43:50 +0300

> I don't see why not, as long as it doesn't change the underlying "core" syntax.

I rechecked SIEVE ABNF myself and didn't find any problems.