[ I think the first part was truncated in the original message. ]
> First off, I assume we're talking about "keywords" as defined in
> RFC3501 section 2.3.2 - or at least, I use the word "defined" loosely,
> because the word "keyword" just sort of appears out of nowhere in that
> section without any definition at all, and the BNF doesn't amplify the
> situation much.
>
> My client is Pegasus Mail - it has had IMAP support for about 14 years
> now, but that support never been very advanced or ambitious, mostly
> because in the very early days I ran into so many inconsistencies with
> server implementations that I never felt it was safe to use anything
> other than the most basic functions of the protocol (and even then I've
> had my share of problems). Keywords are one of the things I've always
> avoided, simply because in the early stages, I found that some servers
> either did not support client-defined keywords, or defined them in
> variable ways that made them difficult to use. As a general rule, you
> can't hang an entire piece of functionality on a feature that might or
> might not be implemented in the server, so it was best simply to avoid
> keywords altogether. Instead, I check for specific message headers
> and allow the user to define others. My client code is very heavily
> cached, so the overhead of examining the headers is only a one-time
> hit in most cases, and a hit that has to be done for other reasons in
> any event.
>
> [ As an aside, I've just re-read the section of RFC3501 on keywords
> and find that it's still server-optional whether they can be client-defined,
> which effectively renders them all but useless, in my view. ]
>
> Unfortunately, one of the problems with a very long legacy is that
> decisions made early in the life cycle can be hard to reverse at a later
> stage. I'm currently engaged in a total rewrite of my message store
> code: some of the code there is nearly 20 years old, and it's *really*
> showing its age, so however painful, a total reappraisal and
> redevelopment using more modern techniques and tools has become
> unavoidable. As part of the rewrite, my IMAP code is getting rewritten
> and much more compartmentalized allowing it to be much freer in how
> it goes about doing a wide range of tasks. I expect this to allow me to
> use facilities like keywords if it seems appropriate, and to make it
> much easier to add support for such facilities if it becomes appropriate
> in future.
>
>> > I'd also really like to know if the client has "this is spam" or "this
>> > is not spam" buttons in the UI, and if it does how those buttons
>> > interact with the use of keywords.
>
> Pegasus Mail has various spam-fighting facilities, including a regex-
> based content processing engine and a full Bayesian spam filter.
> Identifying a message as spam is simply a matter of moving it into the
> spam folder. Similarly, indicating that a message that is in the spam
> folder is not spam is simply a matter of moving it out of the folder to
> any other location. There is also a clickable status button that can be
> used for in-place evaluation and reclassification, although our
> experience is that most users are more at home with the "move-
> in/move-out" paradigm. None of the built-in anti-spam features has any
> interaction with any IMAP keyword at any level, although it would be
> very convenient if there were one I could use reliably.
>
>> > I ask this because users of any client that has such buttons are clearly
>> > going to use those buttons preferentially over any other labelling
>> > mechanism. And if a significant number of clients have such buttons that
>> > do a particular thing - regardless of what that thing is - that's pretty
>> > much going to be determinative in finding the most easily deployed
>> > approach.
>
> Speaking purely as a client developer (since I develop both client and
> server IMAP code), if there were a formally-defined keyword that I
> could reliably expect to find on all server implementations, then I'd
> definitely use it, but otherwise I won't go near it. It's really a pretty
> simple equation for me - IMAP is only a part of my message store
> strategy, and I can't shape the entire way I work on the basis of what it
> does and does not support (I suspect this may be a fairly common
> conundrum for client developers, but have no hard evidence of that).