headers
Lyndon Nerenberg | 25 Aug 2009 05:12
Picon

[Imap-protocol] Survey Results for Spam-related keyword usage by IMAP clients.

I realize this is a bit later than promised, but I was holding out hope 
for (more) responses.

The results were underwhelming. Two unofficial reports of client 
behaviour, and a note from Mark describing how their server products look 
at spam-related keywords.

Apparently SPAM isn't an issue after all.

I'll let Mark elaborate about his stuff if he thinks it's relevant. The 
rest of the info was anecdotal and shouldn't go into the record.

--lyndon
_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 0 comments |
headers
Lyndon Nerenberg - VE6BBM/VE7TFX | 28 Aug 2009 00:44
Picon

[Imap-protocol] [Redux] Spam-related keyword usage survey

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 <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lyndon Nerenberg - VE6BBM/VE7TFX | 28 Aug 2009 00:52
Picon

[Imap-protocol] Resending David Harris' Keyword Comments

[ 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane