[Spambayes] imapfilter

[Meyer, Tony]

> I finally found a little time to suck down and try to install 
> the imapfilter.  Unfortunately, I didn't get too far (see 
> below).  I've read a bunch of recent archive articles and I 
> was just wondering -- has there been any thought about 
> piggybacking imapfilter on Twisted?

Not sure if you saw this in the -dev list or not, but I'm writing a
pop3proxy/imapserver combination thing at the moment (with the grandiose
hope of letting Spambayes with OE be almost as simple as Spambayes with
Outlook).  Based on -dev advice I'm using twisted as the base for the
imapserver.

I haven't really looked at the client side of the twisted code, but the
server part is definitely not ready to use yet (although the bugs are
getting fixed pretty quickly after I submit them, so things are
improving).  If the client side is similar, then it would definitely be
better to stick with imaplib.

I have thought about moving imapfilter over (once I'm done with the
other stuff), but (a) that means forcing users to install twisted, (b)
using imaplib works (for the most part), and (c) twisted is complicated,
and I'm not sure I see any real gain from doing so.

> In any event, I have a couple of minor patches which I'd like 
> to check in (like not trying to unpack the password option if 
> -p is given), if that's okay.

Absolutely.  I'll apply them ASAP.

>   File "imapfilter.py", line 322, in get_substance
>     response = imap.uid("FETCH", self.uid, self.rfc822_command)
[...]
>     raise self.error('%s command error: %s %s' % (name, typ, data))
> imaplib.error: UID command error: BAD ['Bogus attribute list 
> in UID FETCH'] -----snip snip-----

I only noticed in the last week that "RFC822.PEEK" is valid in imap4,
but not imap4rev1.  What imapfilter currently does is try "RFC822.PEEK"
(which is the better command to use), and if that fails, falls back on
"RFC822" (and remember this for next time).

The problem is that the 'bad' response is raised, whereas a 'no'
response is simply returned.  Imapfilter currently works with a 'no'
response, but not with a 'bad' one.  I'll check in a fix for this.
'bad' is the correct response, but the imap server I was testing with
(Courier) returns 'no', so that's what it handles.

=Tony Meyer