Philip Guenther wrote:
Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com> writes:
Arnt Gulbrandsen wrote:
...
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.
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.
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.
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?