Oops -- I spoke too soon. There were valid replies, but my summary
missed them due to a corrupted mail folder screwing up my results
search. My apologies to the two Davids! Their responses are included
below (along with Mark's server commentary).
* Client: Pegasus
* From: David.Harris@pmail.gen.nz
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).
* Client: Thunderbird
From: bienvenu@davidbienvenu.org
We store Junk/NonJunk keywords when either the user or the bayesian junk
filter have determined a message to be spam/not spam. We treat any message
with a keyword containing the strings "NonJunk" or "NotJunk" (for mail.app)
as a spam message, and if we don't find those strings in the keywords, if
we find "Junk" in any keyword, we treat the message as spam. So we'll
treat $Junk as junk, for example. We do a case-insensitive find on the
sub-strings.
* Server: M*Guardian
* From: mrcrispin@Panda.COM
This isn't done by an IMAP client, but it is exposed to IMAP clients by our
product.
We use the following keywords in M+Guardian. We quarantine both incoming
and outgoing. The content and attachment quarantines are based upon site
configurable policy.
$MPlusSpam quarantined due to spam
$MPlusVirus quarantined due to virus
$MPlusContent quarantined due to text content
$MPlusAttach quarantined due to attachment
$MPlusOutbound outbound vs. inbound message (e.g., you sent
something that you aren't allowed to send)