MBOX-Line: From lyndon at orthanc.ca  Thu Aug 27 15:44:24 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] [Redux] Spam-related keyword usage survey
Message-ID: <e0e7d4217140dffcc2265b5880ba0fe5@yyc.orthanc.ca>

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)


