MBOX-Line: From lyndon at orthanc.ca  Thu Aug 27 15:52:10 2009
To: imap-protocol@u.washington.edu
From: Lyndon Nerenberg - VE6BBM/VE7TFX <lyndon@orthanc.ca>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] Resending David Harris' Keyword Comments
In-Reply-To: <4A666F2E.25104.17C99307@David.Harris.pmail.gen.nz>
Message-ID: <926163938893b2f2c230a2d5b1acb908@yyc.orthanc.ca>

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


