Subject: An imapflags question

From: Aaron Stone <[email-masked]>
Date: Wed, 14 Sep 2005 23:58:48 -0700

Several places in the imapflags draft, there are flags such as this one,
starting with a $ rather than \\

           addflag "MyFlags" ["\\Answered", "$MDNSent"];

I presume that this is not a variable, but actually a flag that begins
with $. Where in the specs did those come from? Is this the "keywords"
type flag that RFC 3501 allows?

If it is the "keywords" type flags, I think it would it be prudent to
make reference to that aspect of RFC 3501.

Thanks!
Aaron

---

From: Dave Cridland <[email-masked]>
Date: Thu, 15 Sep 2005 10:21:58 +0100

> make reference to that aspect of RFC 3501.

It does state that "Setflag is used for setting [IMAP] flags or 
keywords."

This may not be clear enough, however, I usually read "flags" as 
"system flags or keywords" in any case. The only distinctions in IMAP 
itself that springs to mind is that system flags can affect, or be 
affected by, the IMAP server (\Seen, \Deleted, \Recent - but not 
\Answered, \Flagged or \Draft) and that system flags have shorthand 
search criteria (ANSWERED, UNSEEN, etc). Otherwise, they behave 
identically.

The $ prefix is not specified in any RFC, as far as I'm aware, and is 
purely a convention for standard keywords.

Dave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 15 Sep 2005 12:24:38 +0200

Dave Cridland writes:
> The only distinctions in IMAP itself that springs to mind is that 
> system flags can affect, or be affected by, the IMAP server (\Seen, 
> \Deleted, \Recent - but not \Answered, \Flagged or \Draft) and that 
> system flags have shorthand search criteria (ANSWERED, UNSEEN, etc). 
> Otherwise, they behave identically.

Which reminds me - as I read the imapflags draft, it's not clear whether 
\recent can be changed using removeflag (and once removed, set again 
using setflag).

I suggest that removeflag should NOT be able to modify \recent, since 
similar IMAP commands cannot set it either. hasflag could test it 
(since similar IMAP commands can) but considering that the result is 
true always, I don't see much value in allowing \recent for hasflag.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Sep 2005 16:00:27 +0100

> search criteria (ANSWERED, UNSEEN, etc). Otherwise, they behave 

Correct.

> purely a convention for standard keywords.

There was a discussion about documenting this convention, but there is 
no document yet.

---

From: Tim Showalter <[email-masked]>
Date: Thu, 15 Sep 2005 14:28:07 -0700

Arnt Gulbrandsen wrote:
> similar IMAP commands cannot set it either. hasflag could test it (since 
> similar IMAP commands can) but considering that the result is true 
> always, I don't see much value in allowing \recent for hasflag.

I wholeheartedly agree; \Recent is typically not modifyable (given Cyrus 
mail stores that I remember, and presumably UW stores as well), and we 
don't want to even suggest that it should be modifyable.

(\Recent can be implemented with timestamps, but not if it's modifyable.)

Tim

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Sep 2005 22:11:07 +0100

Arnt Gulbrandsen wrote:

> Which reminds me - as I read the imapflags draft, it's not clear 
> whether \recent can be changed using removeflag (and once removed, set 
> again using setflag).
>

I think \recent should be explicitly excluded.
I've added to section 2.1:

   Note that it is not possible to use this extension to set or clear the
   \Recent flag or any other special system flag which is not settable
   in [IMAP]. If the \Recent flag is included in a flag list, it MUST be
   silently ignored, but a warning message SHOULD be logged by the Sieve
   interpreter.

---

From: Philip Guenther <[email-masked]>
Date: Sun, 18 Sep 2005 20:28:56 -0700

>Arnt Gulbrandsen wrote:
...
>   silently ignored, but a warning message SHOULD be logged by the Sieve

That makes the handling of \recent match that of flag names that don't
match the IMAP syntax for flag names, which seems right to me.

However, the suggestion that the implementation should log these events
is kinda weird.  In my experience, admins have *no* interest in being
bothered by this stuff.  Indeed, providing users with an automated way
to bother admins would be considered a DoS attack by some people.  The
problem is that it's notifying the wrong party: the author of the script
should be notified, not the admin.  IMHO, invalid flag names and flags
that can't be set (like \recent) should either be silently ignored or be
considered an actual error.

Philip Guenther

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 19 Sep 2005 08:50:53 -0700

> considered an actual error.

Who says the log has to be something read by an admin instead of a user?

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Sep 2005 16:05:16 +0100

>considered an actual error.
As Rob pointed out, the draft doesn't actually say what kind of logging 
should be done.
Some kind of user specific logging would be useful, so that people can 
answer a question like "why such and such flag is not being set".

Should I change the "SHOULD" to "should"?
Should the draft explain this in more details?

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 22 Sep 2005 19:51:54 +0200

On Wed, 2005-09-21 at 16:05 +0100, Alexey Melnikov wrote:
> >[...]
> >bothered by this stuff.

as long as there is no facility for accessing such logs in Sieve, I
think the spec shouldn't be mentioning any.  what gets logged or not is
an administrative issue.

I'd drop the text after the comma, and also remove the "silently", since
it may be taken to mean that no logging is allowed.  what happens to
special system flags other than \Recent?  shouldn't the behaviour be the
same?  suggested replacement text (only the last sentence is different):

        Note that it is not possible to use this extension to set or
        clear the \Recent flag or any other special system flag which is
        not settable in [IMAP]. Any such flags MUST be ignored if
        included in a flag list.

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Sep 2005 18:59:52 +0100

Kjetil Torgrim Homme wrote:

>same?
Yes, even though there is no other special flag at the moment.

>suggested replacement text (only the last sentence is different):
>
Done.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 22 Sep 2005 19:42:00 -0700

Kjetil Torgrim Homme <[email-masked]> writes:
...
>think the spec shouldn't be mentioning any.  what gets logged or not is

Exactly.  I like your suggested text too.

Philip Guenther