[Spambayes] IMAP Problem...and solution

[Tiller, Michael (M.M.)]

I'm trying to get SpamBayes 1.0a7 to work with the
Mercury IMAP server (a Win32 based IMAP server).  I
have had problems for a while but I never had time
until now to actually sit down and workout what the
problem was.  Here is my summary.  Hopefully these
changes can be folded back into the source...

First, the problem I was having was that I would try
and run the IMAP filter with the following command:

python sb_imapfilter.py -c -t -v -l 5

and then I would get this error:

Traceback (most recent call last):
  File "sb_imapfilter.py", line 838, in ?
    run()
  File "sb_imapfilter.py", line 824, in run
    imap_filter.Train()
  File "sb_imapfilter.py", line 646, in Train
    num_ham_trained = folder.Train(self.classifier,
False)
  File "sb_imapfilter.py", line 573, in Train
    msg.get_substance()
  File "sb_imapfilter.py", line 372, in get_substance
    data = _extract_fetch_data(response[1][0])
  File "sb_imapfilter.py", line 158, in
_extract_fetch_data
    mo = FETCH_RESPONSE_RE.match(response)
TypeError: expected string or buffer

So I looked in _extract_fetch_data and there is a call
that look like:

    mo = FETCH_RESPONSE_RE.match(response)

There is a check to make sure that "mo" isn't equal to
"None", but there is no check to make sure that
"response" isn't None to begin with.  So I looked
where _extract_fetch_data is called.  That call looks
like this:

        data = _extract_fetch_data(response[1][0])

After examining this, I found that the value of
response *in this context* (note two different
variables named response), was a tuple containing
("OK", None).

That explains how a None get passed to
_extract_fetch_data.  So, now how to fix it?  Well,
looking at get_substance (the routine that calls
_extract_fetch_data) shows that perhaps the exact set
of commands is not well defined. :-)

Specifically, the routine appears to try and use
"RFC822.PEEK" as the rfc822_command.  Then it traps
errors on that and tries "RFC822" instead.  Very
interesting. All this while the comments in the
routine say that it should be using "BODY.PEEK" ?!?!?

I changed the code to use "BODY.PEEK" and...not
surprisingly I guess...it worked!!!

I'm not sure why it is setup the way it is now, but I
see two ways to remedy this.  First, add a command
line switch to choose what command to use
("RFC822.PEEK", "RFC822" or "BODY.PEEK") as the
initial attempt.  The alternative is to add an
additional check after attempting "RFC822.PEEK" that
checks for a response that looks like ("OK", None) and
then key off of that to switch to "BODY.PEEK".

Since I know what IMAP server I'm working with, I've
just changed the default in init().

Comments?

--
Mike