Re: [PATCH] IMAP old message status on read-only folders
On 2006-01-20 at 13:34 -0800, Brendan Cully wrote:
> This code was rewritten because the recent flag tends to disappear a
> lot (if you use multiple clients, including biffs). You get a lot of
> messages marked O that should be N. Now you lose the O flag if you
> can't write to the mailbox, but I believe this is how other mailbox
> formats work too.
I use mutt and gbuffy; gbuffy correctly uses EXAMINE instead of SELECT
and an IMAP server should not be updating \Recent based on an EXAMINE.
Cyrus doesn't.
RFC 3501, 2.3.2. Flags Message Attribute:
\Recent
Message is "recently" arrived in this mailbox. This session
is the first session to have been notified about this
message; if the session is read-write, subsequent sessions
will not see \Recent set for this message. This flag can not
be altered by the client.
Although that doesn't explicitly say that a read-only session won't
reset \Recent, the implication is clear.
> this takes us back to mutt's old behaviour, which was too vulnerable
> to the whims of the recent flag. I like the current behaviour better.
If I make it a mutt configurable option defaulting to your preferred
behaviour, would that be acceptable? I'd go for the simpler code
change, flagging all unseen non-recent mails, but combining it with the
mutt option.
> I'm a little confused about why you don't have write access to your
> folders, but I think mutt's "old" response is now basically the same
> for IMAP and mbox.
Shared folders for access by multiple members of staff; Cyrus doesn't
have normal flag attributes be per-user, they're shared. Of the top of
my head, that's correct.
Storing flags assumes that the folder is the "property" of the user, to
be amended at will.
For per-user flags such as mutt uses, the ANNOTATE capability's
extensions would need to be used; see draft-ietf-imapext-annotate-14.txt
for more details, but in essense you get an attribute name, which can be
set .priv or .shared, all values per-user. Since it's still a moving
target, even if I wrote a patch to support it I'd suggest leaving it as
a contrib patch. ;^)
So, how about an boolean option called imap_old_recentbased defaulting
to off ?
Alternatively, since the patch I submitted before carefully uses the new
semantics _if_ the server supports the old flag, perhaps that's close
enough? I could change the detection logic to use imap_has_flag()
instead, which would then use \* as well as "old" ?
--
I am keeping international relations on a peaceable footing.
You are biding your time before acting.
He is coddling tyrants.
-- Roger BW on topic of verb conjugation