Re: sieve 13, corrections made during last-call discussion

[Ken Murchison <[e-mail]>]

Tim Showalter wrote:
> 
> Ken Murchison <[e-mail]> writes:
> 
> > > 2.4.2.3. Addresses
> > >
> > > A number of commands call for email addresses, which are also a subset
> > > of strings.  These addresses must be compliant with [IMAIL].
> > > Implementations are required to parse as specified by the "mailbox"
> > > definition in section 6.1, not as "address" is specified in that
> > > section.  "Group" syntax MUST NOT be used (if multiple addresses are
> > > requierd, use a string-list).
> >
> >   ^^^^^^^^
> >
> > Are you punting on the fact that "mailbox" allows "route"?  Or do you
> > want to restrict "mailbox" to:
> >
> > mailbox       = addr-spec
> >       / phrase "<" addr-spec ">"
> 
> That is the restriction I want.  source routes are obsolete, are listed
> as obsolete in drums, and I see no reason to allow them.
> 
> New text:
> 
>         A number of commands call for email addresses, which are also a
>         subset of strings.  These addresses must be compliant with
>         [IMAIL].  Implementations are required to parse as specified by
>         the "mailbox" definition in section 6.1, with the additional
>         constraint that the "route" part MUST NOT be used.  Note that
>         the "address" part specified in section 6.1 is not the syntax
>         part used here: "group" syntax MUST NOT be used (if multiple
>         addresses are requierd, use a string-list).  Implementations
>         MUST ensure that the addresses are syntactically valid, but need
>         not ensure that they actually identify an email recipient.


Well, I understand what we're talking about here because we've hashed it
out before.  But it seems like we have more text telling us what sieve
does NOT support rather than what it does.  Might it just be simpler to
say that email addresses used in sieve actions MUST follow this syntax:

sieve_addr	= addr-spec
		/ phrase "<" addr-spec ">"

where 'addr-spec' and 'phrase' are as defined in [IMAIL] section 6.1.

Here's another fly in the ointment: What about 'domain-literals'?  Even
[IMAIL] discourages that they be used.  Should we just define the syntax
of what sieve should support in its entirety, or am I just being a pain
in the ass now?  (taking a 4 year-old trick-or-treating will do that to
you :^)

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: by ns.secondary.com (8.9.3/8.9.3) id SAA24666 for ietf-mta-filters-bks; Tue, 31 Oct 2000 18:46:54 -0800 (PST)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24662 for <[e-mail]>; Tue, 31 Oct 2000 18:46:53 -0800 (PST)
Received: from ppp4.oceana.com (authenticated) by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id eA12qcr20552; Tue, 31 Oct 2000 21:52:38 -0500
Message-ID: <[e-mail]>
Date: Tue, 31 Oct 2000 21:53:22 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: sieve 13, corrections made during last-call discussion
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:
> 
> Ken Murchison <[e-mail]> writes:
> 
> > > 2.4.2.3. Addresses
> > >
> > > A number of commands call for email addresses, which are also a subset
> > > of strings.  These addresses must be compliant with [IMAIL].
> > > Implementations are required to parse as specified by the "mailbox"
> > > definition in section 6.1, not as "address" is specified in that
> > > section.  "Group" syntax MUST NOT be used (if multiple addresses are
> > > requierd, use a string-list).
> >
> >   ^^^^^^^^
> >
> > Are you punting on the fact that "mailbox" allows "route"?  Or do you
> > want to restrict "mailbox" to:
> >
> > mailbox       = addr-spec
> >       / phrase "<" addr-spec ">"
> 
> That is the restriction I want.  source routes are obsolete, are listed
> as obsolete in drums, and I see no reason to allow them.
> 
> New text:
> 
>         A number of commands call for email addresses, which are also a
>         subset of strings.  These addresses must be compliant with
>         [IMAIL].  Implementations are required to parse as specified by
>         the "mailbox" definition in section 6.1, with the additional
>         constraint that the "route" part MUST NOT be used.  Note that
>         the "address" part specified in section 6.1 is not the syntax
>         part used here: "group" syntax MUST NOT be used (if multiple
>         addresses are requierd, use a string-list).  Implementations
>         MUST ensure that the addresses are syntactically valid, but need
>         not ensure that they actually identify an email recipient.


Well, I understand what we're talking about here because we've hashed it
out before.  But it seems like we have more text telling us what sieve
does NOT support rather than what it does.  Might it just be simpler to
say that email addresses used in sieve actions MUST follow this syntax:

sieve_addr	= addr-spec
		/ phrase "<" addr-spec ">"

where 'addr-spec' and 'phrase' are as defined in [IMAIL] section 6.1.

Here's another fly in the ointment: What about 'domain-literals'?  Even
[IMAIL] discourages that they be used.  Should we just define the syntax
of what sieve should support in its entirety, or am I just being a pain
in the ass now?  (taking a 4 year-old trick-or-treating will do that to
you :^)

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA10846 for ietf-mta-filters-bks; Tue, 31 Oct 2000 14:37:10 -0800 (PST)
Received: from mail.mirapoint.com (IDENT:[e-mail] [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10839 for <[e-mail]>; Tue, 31 Oct 2000 14:37:09 -0800 (PST)
Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com (Mirapoint) with SMTP id AAN96392; Tue, 31 Oct 2000 14:43:17 -0800 (PST)
X-Spook: Monica Lewinsky Ruby Ridge Panama KGB encryption plutonium Croatian
To: Ken Murchison <[e-mail]>
Cc: [e-mail]
Subject: Re: sieve 13, corrections made during last-call discussion
References: <[e-mail]> <[e-mail]>
From: Tim Showalter <[e-mail]>
Date: 31 Oct 2000 14:43:20 -0800
In-Reply-To: Ken Murchison's message of "Tue, 31 Oct 2000 09:39:37 -0500"
Message-ID: <[e-mail]>
Lines: 34
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ken Murchison <[e-mail]> writes:

> > 2.4.2.3. Addresses
> > 
> > A number of commands call for email addresses, which are also a subset
> > of strings.  These addresses must be compliant with [IMAIL].
> > Implementations are required to parse as specified by the "mailbox"
> > definition in section 6.1, not as "address" is specified in that
> > section.  "Group" syntax MUST NOT be used (if multiple addresses are
> > requierd, use a string-list).
> 
>   ^^^^^^^^
> 
> Are you punting on the fact that "mailbox" allows "route"?  Or do you
> want to restrict "mailbox" to:
> 
> mailbox	= addr-spec
> 	/ phrase "<" addr-spec ">"

That is the restriction I want.  source routes are obsolete, are listed
as obsolete in drums, and I see no reason to allow them.

New text:

        A number of commands call for email addresses, which are also a
        subset of strings.  These addresses must be compliant with
        [IMAIL].  Implementations are required to parse as specified by
        the "mailbox" definition in section 6.1, with the additional
        constraint that the "route" part MUST NOT be used.  Note that
        the "address" part specified in section 6.1 is not the syntax
        part used here: "group" syntax MUST NOT be used (if multiple
        addresses are requierd, use a string-list).  Implementations
        MUST ensure that the addresses are syntactically valid, but need
        not ensure that they actually identify an email recipient.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA05700 for ietf-mta-filters-bks; Tue, 31 Oct 2000 13:41:02 -0800 (PST)
Received: from rembrandt.esys.ca (IDENT:[e-mail] [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05694 for <[e-mail]>; Tue, 31 Oct 2000 13:40:52 -0800 (PST)
Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e9VLl6C14440; Tue, 31 Oct 2000 14:47:06 -0700
Message-ID: <[e-mail]>
Date: Tue, 31 Oct 2000 14:47:06 -0700
From: Alexey Melnikov <[e-mail]>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
CC: [e-mail]
Subject: Re: draft-melnikov-sieve-imapflags-04.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <19f801c04270$5f2451c0$73c8d781@nige>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am going on holidays, so reply today or wait for my response till my return in 2 weeks.

Nigel Swinson wrote:

> > > >    1. Do we want to use special actions that work with global state or use optional tagged arguments?
> > > >       Allow both? Currently the draft allows both models.
> > >
> > > As stated earlier (in response to Tim's post) I'm in favor of both.
> >
> > Me too.
> > Any other voices?
> I think so too.

Great.

> Given that setting IMAP flags is kinda a non-destructive operation, then I think we should use the globalflags by default on keep and fileinto.  Then I recon one of the following should allow us to file messages with no flags.
>
> keep :flags NIL
> keep :flags ""
> keep :flags "None"
> keep :flags []
>
> The [] is kinda already handled with the list processing, "" will give us a null flag name which will give us the same kind of thing as an empty list, but NIL is the most readable (although perhaps only for coders who are used to Nils and Nulls).

I would rather not introducing new language construction like NIL. :flags "" or :flags [] are fine with me.

> NIL might however be a bit more annoying to parse as up till now we only excepted a " or [ next after :flags, but readablility should be quite a high goal as it's hopefully not just going to be coders who will want to write SIEVE.  I'm not all that keen on :noflags given that one of the above options works fine.  The less syntax or arguments the better.
>
> At the moment I vote we adopt :flags [] and :flags "None" and where we find something like :flags "" or :flags ["","","None"] then we can default to no flags.

:flags "None" will be confusing, because you can define IMAP flag "None" (name is meaningless, but nevertheless)

> > > 2. The same results can be obtained using existing mechanisms.
> > > Examples:
> > >
> > > keep :globalflags;              =       keep;   (see point 2. above)
> > > keep :globalflags_plus "foo";   =       addflag "foo"; keep; removeflag "foo";
> > > keep :globalflags_minus "foo";  =       removeflag "foo"; keep; addflag "foo";
> >
> > Although it is mathematically equivalent, it is not very convenient :-).
>
> Actually are they equivalent?  Suppose foo is not already set in the second example and we remove the unset flag.  using removeflag.  We will then have altered the global flags by the set of calls.

I guess you are right. I wasn't very attentive.

> It was suggested earlier that we have:
>
> keep :globalflags+ [...]  - stored flags are global flags with additional flags
> keep :globalflags- [...]  - stored flags are global flags with some removed
> keep :globalflags   - use only global flags, the default
> keep :flags [...]   - stored flags are only those listed - global flags are ignored
>
> I quite liked this set of syntax.  What was wrong with it?  Are + and - annoying characters?

The problem is that SIEVE grammar doesn't allow '+' or '-' in a name of tagged argument.

>  If they are I'd go for:
>
> keep :globalflags :plus [...]
> keep :globalflags :minus [...]
>
> Which might even be better than :globalflags+ and definately better than :globalflags_plus.

In this case it is better to have ":globalflags plus [...]" or ":globalflags minus [...]" (no colon in front of plus/minus), because it is confusing (tagged argument that requires another argument, hrrrrr ).

> > 3. Actions
> > <snip>
> >  The "setflag" action replaces the existing set of flags with a new set.
>
> I would expect a setflag to operate on just the one flag though.  Should this be called setflags, setflagsto or resetflags to describe more the fact that you aren't just setting a flag, but blanking all previously set flags?

This is the intent. Can you suggest better wording?

>  removeflag and addflag don't seem to confuse me as much though as they 'update' the existing set of flags.  Or we could have:
>
> globalflags :add [...] - Add the named flags
> globalflags :remove [...] - Remove the named flags
> globalflags :reset - Remove all set flags
> globalflags :setto [...] - Remove all set flags and set to the named flags, equivalent to :reset then :add [...]

"globalflags :reset" is equivalent to "globalflags :setto []".

Although I don't mind your proposal, I would like to see strong support from people to change the syntax.

> I'd suggest it was just "flags :add ..." but then that might cause confusion with "file :flags ..."

Yep.

> I suppose the :setto could be remove to simplify the syntax, but might work quite well as a convenience, it also leaves neat room to add more stuff on globalflags in the future.  I quite like this, I think it reads better.
>
> ------------
>
> "keep :globalflags;" Now seems like a strange statement.  It looks like you are keeping global flags, not keeping a message using the global flags.   I suppose "keepmessage :globalflags;" would be clearer but I guess it's too far down the line to change something like this...

You probably don't want to change base SIEVE spec before last call :-).

> (By the way, the link on the http://www.cyrusoft.com/sieve/ page that points to http://search.ietf.org/internet-drafts/draft-melnikov-sieve-imapflags-03.txt doesn't work.)
>
> Comments welcomed, flames expected.... :o)

Thanks for feedback.

Alexey




Received: by ns.secondary.com (8.9.3/8.9.3) id GAA24711 for ietf-mta-filters-bks; Tue, 31 Oct 2000 06:34:50 -0800 (PST)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24707 for <[e-mail]>; Tue, 31 Oct 2000 06:34:49 -0800 (PST)
Received: from ken.oceana.com (authenticated) by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id e9VEeQr27199; Tue, 31 Oct 2000 09:40:26 -0500
Message-ID: <[e-mail]>
Date: Tue, 31 Oct 2000 09:39:37 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: sieve 13, corrections made during last-call discussion
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:
> 
> I am making the following changes for the last (next) version of Sieve.
> I am going to review the document and try and find any last lingering
> editorial problems and send the document off for IESG review (uh,
> hopefully it's still lingering there, the RFC editor certainly doesn't
> seem to have it yet).
> 
> Here are the changed sections (aside from typos).  If you don't like
> them, please let me know.  If you like them, please disagree with all
> the people that don't like them.
> 
> 2.4.2.3. Addresses
> 
> A number of commands call for email addresses, which are also a subset
> of strings.  These addresses must be compliant with [IMAIL].
> Implementations are required to parse as specified by the "mailbox"
> definition in section 6.1, not as "address" is specified in that
> section.  "Group" syntax MUST NOT be used (if multiple addresses are
> requierd, use a string-list).

  ^^^^^^^^

Are you punting on the fact that "mailbox" allows "route"?  Or do you
want to restrict "mailbox" to:

mailbox	= addr-spec
	/ phrase "<" addr-spec ">"


I don't care either way, but since we had discussed this in the past, I
just wanted to clarify.  That being said, I think the text above is
unambiguous and I am comfortable with it (just have to change the start
state in the cmu-sieve yacc grammar :^).

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: by ns.secondary.com (8.9.3/8.9.3) id RAA26563 for ietf-mta-filters-bks; Mon, 30 Oct 2000 17:08:24 -0800 (PST)
Received: from mail.mirapoint.com (IDENT:[e-mail] [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26559 for <[e-mail]>; Mon, 30 Oct 2000 17:08:23 -0800 (PST)
Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com (Mirapoint) with SMTP id AAN92036; Mon, 30 Oct 2000 17:14:21 -0800 (PST)
X-Spook: Ortega ECHELON PLO DES Saddam Hussein AK-47 Roswell
To: [e-mail]
Subject: sieve 13, corrections made during last-call discussion 
From: Tim Showalter <[e-mail]>
Date: 30 Oct 2000 17:14:23 -0800
In-Reply-To: Ken Murchison's message of "Wed, 23 Aug 2000 09:23:37 -0400"
Message-ID: <[e-mail]>
Lines: 38
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am making the following changes for the last (next) version of Sieve.
I am going to review the document and try and find any last lingering
editorial problems and send the document off for IESG review (uh,
hopefully it's still lingering there, the RFC editor certainly doesn't
seem to have it yet).

Here are the changed sections (aside from typos).  If you don't like
them, please let me know.  If you like them, please disagree with all
the people that don't like them.

2.4.2.3. Addresses

A number of commands call for email addresses, which are also a subset
of strings.  These addresses must be compliant with [IMAIL].
Implementations are required to parse as specified by the "mailbox"
definition in section 6.1, not as "address" is specified in that
section.  "Group" syntax MUST NOT be used (if multiple addresses are
requierd, use a string-list).  Implementations MUST ensure that the
addresses are syntactically valid, but need not ensure that they
actually identify an email recipient.

2.10.2.  Implicit Keep

Previous experience with filtering systems suggests that cases tend to be
missed in scripts.  To prevent errors, Sieve has an "implicit keep".

An implicit keep is a keep action (see section 4.4) performed in the
absence of any action that cancels the implicit keep.

An implicit keep is performed if a message is not written to a mailbox,
redirected to a new address, or explicitly thrown out.  That is, if a
fileinto, a keep, a redirect, or a discard is performed, an implicit keep is
not.

Some actions may be defined to not cancel the implicit keep.  These
actions may not directly effect the delivery of a message, and are
used for their side effects.  None of the actions specified in this
document meet that criteria, but extension actions will.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA28030 for ietf-mta-filters-bks; Mon, 30 Oct 2000 04:48:46 -0800 (PST)
Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA28026 for <[e-mail]>; Mon, 30 Oct 2000 04:48:45 -0800 (PST)
Received: (cpmta 2246 invoked from network); 30 Oct 2000 04:54:24 -0800
Received: from commercial.ucs.ed.ac.uk (HELO nige) (129.215.200.115) by smtp.swinson.com (209.228.32.65) with SMTP; 30 Oct 2000 04:54:24 -0800
X-Sent: 30 Oct 2000 12:54:24 GMT
Message-ID: <19f801c04270$5f2451c0$73c8d781@nige>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: draft-melnikov-sieve-imapflags-04.txt
Date: Mon, 30 Oct 2000 12:53:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA28027
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > >    1. Do we want to use special actions that work with global state or use optional tagged arguments?
> > >       Allow both? Currently the draft allows both models.
> >
> > As stated earlier (in response to Tim's post) I'm in favor of both.
> 
> Me too.
> Any other voices?
I think so too.

> > >    2. If we decide to keep both, what "keep"/"fileinto" without tagged arguments means: don't set any flags
> > >       or use global flags? I would rather ignore flags completely to keep current "keep"/"fileinto" behavior.
> > >       This breaks backward compatibility with the previous draft and if this is a big concern it can be addressed
> > >       in the next revision of the draft.
> >
> > I think that keep/fileinto without any tagged arguments SHOULD use the
> > global flags.  If someone wants to keep/fileinto a message without the
> > global flags (if any), we could allow one of the following syntaxes:
> >
> > keep :flags "";         OR
> > keep :flags NIL;        OR
> > keep :noflags;
> 
> I would like to hear Tim's opinion on this.
> IMHO, the first works fine for me.
Given that setting IMAP flags is kinda a non-destructive operation, then I think we should use the globalflags by default on keep and fileinto.  Then I recon one of the following should allow us to file messages with no flags.  

keep :flags NIL
keep :flags ""
keep :flags "None"
keep :flags []

The [] is kinda already handled with the list processing, "" will give us a null flag name which will give us the same kind of thing as an empty list, but NIL is the most readable (although perhaps only for coders who are used to Nils and Nulls).  

NIL might however be a bit more annoying to parse as up till now we only excepted a " or [ next after :flags, but readablility should be quite a high goal as it's hopefully not just going to be coders who will want to write SIEVE.  I'm not all that keen on :noflags given that one of the above options works fine.  The less syntax or arguments the better.

At the moment I vote we adopt :flags [] and :flags "None" and where we find something like :flags "" or :flags ["","","None"] then we can default to no flags.

> > >    5. ":globalflags_plus" and ":globalflags_minus" names are ugly. Suggestions are welcome.
<snip>
> > 2. The same results can be obtained using existing mechanisms.
> > Examples:
> >
> > keep :globalflags;              =       keep;   (see point 2. above)
> > keep :globalflags_plus "foo";   =       addflag "foo"; keep; removeflag "foo";
> > keep :globalflags_minus "foo";  =       removeflag "foo"; keep; addflag "foo";
> 
> Although it is mathematically equivalent, it is not very convenient :-).

Actually are they equivalent?  Suppose foo is not already set in the second example and we remove the unset flag.  using removeflag.  We will then have altered the global flags by the set of calls.

It was suggested earlier that we have:

keep :globalflags+ [...]  - stored flags are global flags with additional flags
keep :globalflags- [...]  - stored flags are global flags with some removed
keep :globalflags   - use only global flags, the default
keep :flags [...]   - stored flags are only those listed - global flags are ignored
 
I quite liked this set of syntax.  What was wrong with it?  Are + and - annoying characters?  If they are I'd go for:

keep :globalflags :plus [...]
keep :globalflags :minus [...]

Which might even be better than :globalflags+ and definately better than :globalflags_plus.

----------

Other comments on reading the draft.

> 3. Actions
> <snip>
>  The "setflag" action replaces the existing set of flags with a new set. 

I would expect a setflag to operate on just the one flag though.  Should this be called setflags, setflagsto or resetflags to describe more the fact that you aren't just setting a flag, but blanking all previously set flags?  removeflag and addflag don't seem to confuse me as much though as they 'update' the existing set of flags.  Or we could have:

globalflags :add [...] - Add the named flags
globalflags :remove [...] - Remove the named flags
globalflags :reset - Remove all set flags
globalflags :setto [...] - Remove all set flags and set to the named flags, equivalent to :reset then :add [...]

I'd suggest it was just "flags :add ..." but then that might cause confusion with "file :flags ..."

I suppose the :setto could be remove to simplify the syntax, but might work quite well as a convenience, it also leaves neat room to add more stuff on globalflags in the future.  I quite like this, I think it reads better.

------------

"keep :globalflags;" Now seems like a strange statement.  It looks like you are keeping global flags, not keeping a message using the global flags.   I suppose "keepmessage :globalflags;" would be clearer but I guess it's too far down the line to change something like this...

(By the way, the link on the http://www.cyrusoft.com/sieve/ page that points to http://search.ietf.org/internet-drafts/draft-melnikov-sieve-imapflags-03.txt doesn't work.)

Comments welcomed, flames expected.... :o)

Nigel



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA09750 for ietf-mta-filters-bks; Sun, 29 Oct 2000 21:07:51 -0800 (PST)
Received: from rembrandt.esys.ca (IDENT:[e-mail] [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09745 for <[e-mail]>; Sun, 29 Oct 2000 21:07:50 -0800 (PST)
Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e9U5DtC23945; Sun, 29 Oct 2000 22:13:55 -0700
Message-ID: <[e-mail]>
Date: Sun, 29 Oct 2000 22:13:55 -0700
From: Alexey Melnikov <[e-mail]>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ken Murchison <[e-mail]>
CC: [e-mail], Tim Showalter <[e-mail]>
Subject: Re: draft-melnikov-sieve-imapflags-04.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ken Murchison wrote:

> > 0.2. Open issues
> >
> >    1. Do we want to use special actions that work with global state or use optional tagged arguments?
> >       Allow both? Currently the draft allows both models.
>
> As stated earlier (in response to Tim's post) I'm in favor of both.

Me too.
Any other voices?

> >    2. If we decide to keep both, what "keep"/"fileinto" without tagged arguments means: don't set any flags
> >       or use global flags? I would rather ignore flags completely to keep current "keep"/"fileinto" behavior.
> >       This breaks backward compatibility with the previous draft and if this is a big concern it can be addressed
> >       in the next revision of the draft.
>
> I think that keep/fileinto without any tagged arguments SHOULD use the
> global flags.  If someone wants to keep/fileinto a message without the
> global flags (if any), we could allow one of the following syntaxes:
>
> keep :flags "";         OR
> keep :flags NIL;        OR
> keep :noflags;

I would like to hear Tim's opinion on this.
IMHO, the first works fine for me.

> >    5. ":globalflags_plus" and ":globalflags_minus" names are ugly. Suggestions are welcome.
>
> I think we can get rid of ALL of the :globalflags* options for two
> reasons:
>
> 1. They make the syntax more crufty (and they ARE ugly as you state :^)
>
> 2. The same results can be obtained using existing mechanisms.
> Examples:
>
> keep :globalflags;              =       keep;   (see point 2. above)
>
> keep :globalflags_plus "foo";   =       addflag "foo"; keep; removeflag "foo";
>
> keep :globalflags_minus "foo";  =       removeflag "foo"; keep; addflag "foo";

Although it is mathematically equivalent, it is not very convenient :-).

> Besides, as a current user (and implementer) of imapflags, I really
> haven't come across the need to tweak the global flags on a per
> keep/fileinto basis.  If I did find a need for this, I wouldn't have any
> problem either overiding the globals completely by using :flags or
> bracketing the keep/fileinto with addflag/removeflag as I've shown
> above.
>
> > 5. Interaction with Other Sieve Actions
> >
> >    Sieve actions sometimes  prohibit  each  other  in  order  to  make
> >    filtering scripts less likely to cause serious problems.
> >
> >    The SIEVE interpreter  MUST  ignore any [FM]
> >    actions when they are used  with  reject. The SIEVE interpreter MUST ignore these
> >    commands when no keep (implicit or explicit) or fileinto actions will be taken.
> >
> >    If the script uses any of [FM] actions
> >    together with  reject a SIEVE verifier SHOULD warn the user using available means that
> >    the script contains actions that has no effect when used with reject.
>
> Is it really necessary to make a special case for reject?  What's the
> point of provding a warning?  The [FM] actions are ONLY useful for
> actions that actually deliver messages (keep, fileinto), and all other
> actions (redirect, reject, discard, vacation, etc) should just ignore
> them as stated above.

Ok, you convinced me :-). I'll remove all restrictions on reject/discard.

> One other comment...
>
> I think this has been mentioned before, but none of the [FM] actions
> described in the draft seem very IMAP specific.  Why couldn't these
> mechanisms be used for setting any mailstore specific flags?  Granted,
> no other use comes to mind right now, but shouldn't we error on the side
> of flexibility?  Just a thought... feel free to flame :^)

Do you have anything particular in mind? (Using IMAP Annotations is worth separate draft.)
Do you have any proposals how to change the draft?

Alexey




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA25133 for ietf-mta-filters-bks; Fri, 27 Oct 2000 10:30:29 -0700 (PDT)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25127 for <[e-mail]>; Fri, 27 Oct 2000 10:30:28 -0700 (PDT)
Received: from ken.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id e9RHZkQ20232; Fri, 27 Oct 2000 13:35:50 -0400
Message-ID: <[e-mail]>
Date: Fri, 27 Oct 2000 13:35:17 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: draft-melnikov-sieve-imapflags-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 0.2. Open issues
> 
>    1. Do we want to use special actions that work with global state or use optional tagged arguments?
>       Allow both? Currently the draft allows both models.


As stated earlier (in response to Tim's post) I'm in favor of both.


>    2. If we decide to keep both, what "keep"/"fileinto" without tagged arguments means: don't set any flags
>       or use global flags? I would rather ignore flags completely to keep current "keep"/"fileinto" behavior.
>       This breaks backward compatibility with the previous draft and if this is a big concern it can be addressed
>       in the next revision of the draft.


I think that keep/fileinto without any tagged arguments SHOULD use the
global flags.  If someone wants to keep/fileinto a message without the
global flags (if any), we could allow one of the following syntaxes:

keep :flags "";		OR
keep :flags NIL;	OR
keep :noflags;


>    5. ":globalflags_plus" and ":globalflags_minus" names are ugly. Suggestions are welcome.

I think we can get rid of ALL of the :globalflags* options for two
reasons:

1. They make the syntax more crufty (and they ARE ugly as you state :^)

2. The same results can be obtained using existing mechanisms. 
Examples:

keep :globalflags;		=	keep;	(see point 2. above)

keep :globalflags_plus "foo";	=	addflag "foo"; keep; removeflag "foo";

keep :globalflags_minus "foo";	=	removeflag "foo"; keep; addflag "foo";


Besides, as a current user (and implementer) of imapflags, I really
haven't come across the need to tweak the global flags on a per
keep/fileinto basis.  If I did find a need for this, I wouldn't have any
problem either overiding the globals completely by using :flags or
bracketing the keep/fileinto with addflag/removeflag as I've shown
above.


> 5. Interaction with Other Sieve Actions
> 
>    Sieve actions sometimes  prohibit  each  other  in  order  to  make
>    filtering scripts less likely to cause serious problems.
> 
>    The SIEVE interpreter  MUST  ignore any [FM]
>    actions when they are used  with  reject. The SIEVE interpreter MUST ignore these
>    commands when no keep (implicit or explicit) or fileinto actions will be taken.
> 
>    If the script uses any of [FM] actions
>    together with  reject a SIEVE verifier SHOULD warn the user using available means that
>    the script contains actions that has no effect when used with reject.


Is it really necessary to make a special case for reject?  What's the
point of provding a warning?  The [FM] actions are ONLY useful for
actions that actually deliver messages (keep, fileinto), and all other
actions (redirect, reject, discard, vacation, etc) should just ignore
them as stated above.


One other comment...

I think this has been mentioned before, but none of the [FM] actions
described in the draft seem very IMAP specific.  Why couldn't these
mechanisms be used for setting any mailstore specific flags?  Granted,
no other use comes to mind right now, but shouldn't we error on the side
of flexibility?  Just a thought... feel free to flame :^)

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA27659 for ietf-mta-filters-bks; Wed, 18 Oct 2000 13:57:26 -0700 (PDT)
Received: from lahontan.crl.dec.com (hoover-2.crl.dec.com [192.58.206.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA27623; Wed, 18 Oct 2000 13:57:15 -0700 (PDT)
From: [e-mail]
Received: by lahontan.crl.dec.com; id AA22727; Wed, 18 Oct 2000 17:04:30 -0400
Date: Wed, 18 Oct 2000 17:04:30 -0400
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Hi, this is for you.....
Mime-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Friend:

Do you need a change in your life?

Do you remember when the entire world seemed like it was
yours for the taking?

Do you remember a time when all of your hopes and dreams seemed
like they were attainable?

First of all, let's be honest. You are not going to earn $50,000 in
20 days. It just isn't going to happen. Anyone who tells you that
you can, is not being truthful.  But, let me tell you about a plan
that can possibly make all your dreams come true...keep reading!

********************************************************************

I would like to tell you about a plan that has changed my life.
Take a calculator and figure in the worst possible scenario. Decide
for yourself. If you decide that you want to take control of your
life and move forward...that is your decision.

********************************************************************

Here's the step by step plan summary.

1)You order the 4 reports listed below ($5 each). They come to you
by email.

2)Save a copy of this entire letter and put your name at report #1.
Move all other names  down. (You will be removing the person at the
level 4)

3)Use any of the hundreds of bulk email services out there.

4)Orders will come right to your door. Simply email them the report
they ordered.Isn't that about as easy as it gets???

********************************************************************

Your cost to participate in this program is practically nothing
(surely you can afford $20 and initial bulk mailing cost). You
obviously already have a computer and an Internet connection and
e-mail is FREE!

The primary method of building your downline is bulk email.

Let's say that you decide to start small, just to see how it goes.
Let's assume that you and all those involved email out only 2,000
programs each. Let's also assume that the mailing receives a 0.5%
response. The response could be much better. Also, many people will
email out more than 2,000 programs. With a 0.5% response, that is
only 10 orders for Report #1.  Those 10 respond  by sending out
2,000 programs each for a total of 20,000.  Out of those 0.5%, 100
people respond and order 20,000.  The 0.5% response rate to that is
1,000 orders for Report #3. Those 1,000 send out 2,000 each for a
total of 2,000,000.  The 0.5% response rate is 10,000 orders for
report #4. That is 10,000 $5 bills for you. CASH!!!

*********************************************************************

Your total income in this example is: $50+ $500+ $5000+ $50,000 for
a total of $55,550!!!

*********************************************************************

REMEMBER FRIEND. THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU
MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!!!  DARE
TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR EVEN HALF
MAILED OUT 100,000 INSTEAD OF 2,000. Believe, most people will do
just that, and more!!!

Friend, you do the math. You look at the opportunity, if you decide
that you would like to participate in this program, the decision is
yours.

Recently, the Federal Trade Commission has tried to stop chain
letters which promise you will make tons of money by participating.  
Such chain letters are NOT legal because of this reason. This new
program complies with all the rules.

To be legal, a chain letter must offer a product and must not
promise you will get rich by taking part. If you look at the
program, do the math and decide that you will make money, it is
your opinion. No such claim is here.

However, I do strongly encourage you to do the calculations.
Figure out the worst possible response and see how it calculates.

Your orders come right to your door and you send your reports via
email. You are not involved in personal selling.

You do it privately in your own home, store, or office. This is the
EASIEST plan anywhere. It is simply order filling by email.

Order the four reports shown on the list below. You can't sell them
if you don't order them!!!.

For each report, send $5.00 CASH, the  NAME & NUMBER OF THE REPORT
YOU ARE ORDERING, YOUR EMAIL ADDRESS, and YOUR NAME AND RETURN
ADDRESS (in case there's a problem).  MAKE SURE YOUR RETURN ADDRESS
IS ON THE ENVELOPE IN CASE OF ANY MAIL PROBLEMS!

Report #1 will tell you how to download bulk email software and
email addresses so you can send it out to thousands while you
sleep. Remember that 50,000+ new people are joining the Internet
every month.

By the way, there are over 50 million email addresses with millions
more joining the Internet each year, so we don't worry about
"saturation".  People are used to seeing and hearing the same
advertisements every day on radio/TV.  How often have you received
the same pizza flyers on your door. Then, one day you are hungry
for pizza and immediately recall the flyer. Same thing with this
letter. I received this letter many times- then one day I decided
it was time to try it.

This program will not require you to come into contact with people
or take any telephone calls. Just follow the instructions.

There is no guarantee either stated or implied that anyone
participating in this program will earn $50,000+.  (You must
include that statement to make this legal.)

******* TIPS FOR SUCCESS *******

TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow
the directions accurately. -- Send for the four reports IMMEDIATELY
so you will have them when the orders start coming in because: When
you receive a $5 order, you MUST send out the requested product/report.

It is required for this to be a legal business and they need the
reports to send out their letters (with your name on them!) -- ALWAYS
PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient
and persistent with this program.

**********************************************************************
Get started TODAY!! Notes- ALWAYS SEND $5 CASH (US CURRENCY) FOR
EACH REPORT.  CHECKS NOT ACCEPTED.  make sure the cash is concealed
by wrapping it in two sheets of paper. On one of those sheets
write: (a) the number and name of the report you are ordering, (b)
your e-mail address, and (c) your name and postal address.


REPORT #1  "The Insider's Guide to Advertising for Free on the
Internet"

ORDER REPORT #1 FROM:

S. STARK
P.O. BOX 61009
HOUSTON, TEXAS 77208-1009


REPORT #2  "The Insider's Guide to Sending Bulk E-mail on the
Internet"

ORDER REPORT #2 FROM:

WAYNE ELLIOTT
11918 SE DIVISION #358
PORTLAND, OR 97266


REPORT #3  "The Secrets to Multilevel Marketing on the Internet"

ORDER REPORT #3 FROM:

RYAN ROMNEY
P.O. BOX 540421
NORTH SALT LAKE, UT  84054-0421


REPORT #4  "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"

ORDER REPORT #4 FROM:

RUSSELL OLSEN
5409 YARMOUTH AVE #3
ENCINO, CA 91316


********************************************************************
This ad is being sent in compliance with Senate Bill 1618, Title 3,
section 301, paragraph (a)(2)(C).

Further transmissions to you by the sender of this e-mail may be
stopped at no cost to you by sending a reply to this e-mail address
with the words "remove" in the subject line.
********************************************************************



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA11828 for ietf-mta-filters-bks; Sun, 15 Oct 2000 20:52:14 -0700 (PDT)
Received: from rembrandt.esys.ca (IDENT:[e-mail] [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11824 for <[e-mail]>; Sun, 15 Oct 2000 20:52:12 -0700 (PDT)
Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e9G3v6C03567; Sun, 15 Oct 2000 21:57:06 -0600
Message-ID: <[e-mail]>
Date: Sun, 15 Oct 2000 21:57:06 -0600
From: Alexey Melnikov <[e-mail]>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Internet Drafts Submission <[e-mail]>
CC: [e-mail]
Subject: draft-melnikov-sieve-imapflags-04.txt
Content-Type: multipart/mixed; boundary="------------CB230F99D207B9BFB90C4E18"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------CB230F99D207B9BFB90C4E18
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

Hopefully it contains less bugs in examples than the previous one.

Alexey


--------------CB230F99D207B9BFB90C4E18
Content-Type: text/plain; charset=koi8-r;
 name="draft-melnikov-sieve-imapflags-04.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-melnikov-sieve-imapflags-04.txt"

Network Working Group                                       
Internet Draft: Sieve -- IMAP flag Extension                 A. Melnikov
Document: draft-melnikov-sieve-imapflags-04.txt   Messaging Direct, Ltd.
Expires: April 2001                                         October 2000


                      Sieve -- IMAP flag Extension


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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 2000.  All Rights Reserved.

Abstract

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

   This document describes an extension to the  Sieve  mail  filtering
   language for setting [IMAP] flags. The extension allows to set both 
   [IMAP] system flags and [IMAP] keywords.


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 <[e-mail]>.  Subscription  requests
   can  be  sent  to <[e-mail]> (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/>.


0.2. Open issues

   1. Do we want to use special actions that work with global state or use optional tagged arguments?
      Allow both? Currently the draft allows both models.

   2. If we decide to keep both, what "keep"/"fileinto" without tagged arguments means: don't set any flags
      or use global flags? I would rather ignore flags completely to keep current "keep"/"fileinto" behavior.
      This breaks backward compatibility with the previous draft and if this is a big concern it can be addressed
      in the next revision of the draft.

   3. Add example that describes why implicit way is useful?

   4. Should the document repeat when describing flag manipulation actions that they have no affect
      if non of ":globalflags", ":globalflags_plus" or ":globalflags_minus" is specified?

   5. ":globalflags_plus" and ":globalflags_minus" names are ugly. Suggestions are welcome.


0.3. To be done

      Text will be reworked not to reference "internal variable".


0.4. Changes from the version submitted to the SIEVE mailing list

   1. Added addflag and removeflag actions

   2. Changed the semantics of setflag (setflag is not additive any more)

   3. Corrected   section  "Interaction  with  Other  Sieve  Actions".
      Removed incorrect reference to  the  forward  action  as  to  an
      action that prohibits setflag.

   4. Added  paragraph  about  the  mutual  order of "fileinto"/"keep" and
      "setflag"/"addflag"/"removeflag" actions.


0.5. Changes from the revision 00

   1. Corrected Capability Identifier section (Section 2)

   2. Corrected "Interaction with Other Sieve Actions" section (Section 4)

   3. Examples were updated to be compatible with Sieve-07 draft

   4. Added "mark" and "unmark" actions


0.6. Changes from the revision 01

   1. Some language fixes based on Tony Hansen comments

   2. Clarified that the extension allows to set both IMAP System Flags and Keywords


0.7. Changes from the revision 02

   1. BugFix: all backslashes must be escaped

   2. Added extended example and more detailed description of "addflag"/"removeflag" additivity.

   3. Minor example bugfixes


0.8. Changes from the revision 03

   1. Added second way to specify flags to be set (via optional tagged arguments). [Tim Showalter]

   2. Rules for using Reject with imapflags relaxed. [Randall Gellens]
 
   3. Removed ABNF section completely, added syntax description to action definition. [Tim Showalter]

   4. Cleaned up the example. [Ken Murchison]

   5. Added [FM] acronym (Flag Manupulation)

   6. Clarified "mark"/"unmark" bahavior. [Randall Gellens}


1. Introduction

   This is  an  extension to the Sieve language defined by [SIEVE] for
   setting [IMAP] flags.  There are two major ways to specify which flags should
   be set: explicit, that lists flags using tagged argument for "keep" and
   "fileinto" and implicit, that uses actions that work with the global state
   ("setflag", "addflag", "removeflag", "mark" and "unmark"). There is also possible
   to combine the advantages of both ways. The first approach is described in section 4.
   The second is described in the sections 3 and 4.

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

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

2. Conventions used.

   Conventions for notations are as in [SIEVE] section 1.1,  including
   use of [KEYWORDS] and "Syntax:" label for the definition of action and tagged arguments syntax.

   Global flags are those that are set by "setflag"/"addflag"/"removeflag"/"mark"/"unmark" actions.

   "[FM]" (Flag Manipulation) acronym references any of "setflag"/"addflag"/"removeflag"/"mark"/"unmark"
   actions.

   The capability string associated with extension defined in this document
   is "imapflags".


3. Actions

   All actions described in this specification (setflag, addflag, removeflag,
   mark, unmark) operate on an internal variable that contains the set of [IMAP] flags
   associated with the message being delivered. When the interpreter starts executing
   a script this variable contains an empty set. The "addflag" action adds flags
   to the existing set. The "removeflag" action removes flags from the existing set. 
   The "setflag" action replaces the existing set of flags with a new set. 
   Whenever the interpreter encounters a "fileinto" or "keep" action it files
   the message with the current set of flags.


3.1. Setflag Action

   Syntax:   setflag <list-of-flags: string-list>

   Setflag is used for setting  [IMAP]  system flags or keywords. Setflag
   replaces  any previously  set  flags.  It  should  be  used together with "keep"
   or "fileinto".  It MUST be ignored  if  mailstore or target mailbox doesn't
   support  the storing of any flags.

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

   The order of "setflag"/"fileinto" or "setflag"/"keep" is important in the
   script. Any setflag action applies only to all subsequent "fileinto"/"keep"
   actions in a script till next occurence of [FM] action.

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

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

   A more substantial example is:

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


3.2. Addflag action

   Syntax:   addflag <list-of-flags: string-list>

   Addflag is used for setting [IMAP] flags. However unlike setflag it
   doesn't replace any previously set flags.  This means that multiple
   occurrences of addflag are treated additively.

   For example, the following two actions

      addflag "\\Deleted";
      addflag "\\Answered";

   produce the same result as the single action

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

   In all other  respects  addflag  behaves  the  same  way  as
   setflag.


3.3. Removeflag Action

   Syntax:   removeflag <list-of-flags: string-list>

   Removeflag is used for  setting  [IMAP]  flags.  Removeflag  clears
   flags previously set by "setflag"/"addflag".  Calling removeflag with a
   flag that wasn't set before is not an error and is ignored.
   Multiple occurrences of removeflag are treated additively.

   In all other respects removeflag behaves  the  same  way  as
   setflag.

      Example:
        if header :contains "Disposition-Notification-To" "[e-mail]" {
            addflag "$MDNRequired";
        }
        if header :contains "from" "[e-mail]" {
            removeflag "$MDNRequired";
            fileinto :globalflags "INBOX.imap-list";
        }


3.4. Mark and Unmark Actions

   Syntax:   mark

   Syntax:   unmark

   The mark action allows a message to be marked as urgent. Conformant implementation MUST
   set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well. Thus the mark  action is
   semantically equivalent to 'addflag "\\Flagged"'.

   The unmark action allows the flag previously  set  by  the Mark action to be unset.
   Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark.
   Unmark MUST NOT unset any other flags. This means that the following script does nothing:

      mark;
      unmark;

   The unmark action is semantically equivalent to 'removeflag "\\Flagged"'.


4. Tagged arguments

   This specification adds several optional tagged arguments that alter the behavior of actions
   "keep" and "fileinto". Only one of the following 4 tagged arguments can be used with "keep" or
   "fileinto". They specify that some flag or combination of flags should be set when they deliver
   the message to the target mailbox. If non of the 4 following tagged arguments is specified, 
   "keep" or "fileinto" will not set any flag when they deliver the message to the mailbox.

   Syntax:   ":globalflags_plus" <list-of-flags: string-list>

   The copy of the message filed into mailbox will have both global flags and flags listed after
   ":globalflags_plus".


   Syntax:   ":globalflags_minus" <list-of-flags: string-list>

   The copy of the message filed into mailbox will have all global flag with exception of flags
   listed after ":globalflags_minus".


   Syntax:   ":globalflags"

   The copy of the message filed into mailbox will have only global flags.


   Syntax:   ":flags" <list-of-flags: string-list>

   The copy of the message filed into mailbox will have only flags listed after ":flags".
   Global flags set by any of [FM] actions are ignored.


5. Interaction with Other Sieve Actions

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

   The SIEVE interpreter  MUST  ignore any [FM]
   actions when they are used  with  reject. The SIEVE interpreter MUST ignore these
   commands when no keep (implicit or explicit) or fileinto actions will be taken.

   If the script uses any of [FM] actions
   together with  reject a SIEVE verifier SHOULD warn the user using available means that 
   the script contains actions that has no effect when used with reject.


6. Other Considerations

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


7. Security Considerations

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


8. Extended example

   #
   # Example Sieve Filter
   # Declare any optional features or extension used by the script
   #
   require ["fileinto", "imapflags"];

   #
   # Move large messages to special mailbox
   #
   if size :over 1M
           {
           addflag "$Big";
           if header :is "From" "[e-mail]"
                      {
   # The message will be marked as "\Flagged $Big" when filed into mailbox "Big messages"
                      addflag "\\Flagged";
                      }
           fileinto :globalflags "Big messages";
           }

   if header :is "From" "[e-mail]"
           {
           addflag ["\\Answered", "$MDNSent"];
   # If the message is bigger than 1Mb it will be marked as "$Big \Answered $MDNSent" 
   # when filed into mailbox "grandma". If the message is shorter than 1Mb it will be marked as
   # "\Answered $MDNSent"
           fileinto :globalflags "GrandMa";  # move to "GrandMa" folder
           }

   #
   # Handle messages from known mailing lists
   # Move messages from IETF filter discussion list to filter folder
   #
   if header :is "Sender" "[e-mail]"
           {
           setflag "\\Flagged";
   # Message will always have just "\Flagged" flag
           keep :globalflags;
           }

   #
   # Keep all messages to or from people in my company
   #
   elsif anyof address :domain :is ["From", "To"] "company.com"
           {
           keep :globalflags;               # keep in "In" folder
           }
   #
   # Try and catch unsolicited email.  If a message is not to me,
   # or it contains a subject known to be spam, file it away.
   #
   elsif anyof (not address :all :contains
                  ["To", "Cc", "Bcc"] "[e-mail]",
                header :matches "subject"
                  ["*make*money*fast*", "*university*dipl*mas*"])
           {
           removeflag "\\Flagged";
           # If message header does not contain my address,
           # it's from a list.
           fileinto :globalflags "spam";   # move to "spam" folder
           }
   else
           {
           # Move all other (non-company) mail to "personal"
           # folder.
           fileinto :globalflags "personal";
           }


9.  Acknowledgments

    This document has been revised in part based on comments and
    discussions which took place on and off the SIEVE mailing list.
    The help of those who took the time to review the draft and make
    suggestions is appreciated, especially that of Tim Showalter,
    Barry Leiba, Randall Gellens, Ken Murchison and Cyrus Daboo.
    Special thanks to Tony Hansen, David Lamb and Roman Migal for helping
    me explain better the concept.


10. Author's Address

    Alexey Melnikov
    Messaging Direct, Ltd.

    Address : #900, 10117 Jasper Avenue, Edmonton, Alberta, Canada,
    T5J1W8

    Email: [e-mail]


Appendices

Appendix A.  References

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language", Mirapoint,
   Work in Progress, draft-showalter-sieve-XX.txt

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

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

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

--------------CB230F99D207B9BFB90C4E18--