Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#85 More resilient parsing for sb_imapfilter

Tony Meyer
Dave Abrahams

On 31 January 2006 I posted this problem that came
up for me trying to do training with sb_imapfilter with the latest

Loading state from /usr/home/dave/ database
/usr/home/dave/ is a new database
Loading database /usr/home/dave/ Done.
Training ham folder HamBox
Traceback (most recent call last):
File "/usr/home/dave/src/spambayes/scripts/", line 1283, in ?
File "/usr/home/dave/src/spambayes/scripts/", line 1261, in run
File "/usr/home/dave/src/spambayes/scripts/", line 1004, in Train
num_trained = folder.Train(self.classifier, is_spam)
File "/usr/home/dave/src/spambayes/scripts/", line 888, in Train
for msg in self:
File "/usr/home/dave/src/spambayes/scripts/", line 799, in __iter__
yield self[key]
File "/usr/home/dave/src/spambayes/scripts/", line 831, in __getitem__
data = self.imap_server.extract_fetch_data(response_data)
File "/usr/home/dave/src/spambayes/scripts/", line 455, in extract_fetch_data
msg_data = self._extract_fetch_data(msg)
File "/usr/home/dave/src/spambayes/scripts/", line 428, in _extract_fetch_data
raise BadIMAPResponseError("FETCH response", response)
__main__.BadIMAPResponseError: The command 'FETCH response' failed to give an OK response.
(' UID 1967)',)

I decided last week to try to debug this a little bit myself. I know
almost nothing about the workings of IMAP, but the problem appears to
be that sb_imapfilter isn't accounting for responses like this one:

'6 (BODY[] {3130}'
, 'Return-Path: <MAILER-DAEMON...about 3000 characters snipped...'
, ' UID 6)'

In particular, that last fragment is where sb_imapfilter gets upset.
I don't know whether the real bug is in whatever gets passed to
sb_imapfilter to be used as its "server" attribute, or whether it's
here, but if you look carefully at the response data structure above,
which is passed back from the server object to sb_imapfilter, you'll
see that the parenthesization that was in the original text coming
back from the real IMAP server (i.e. a computer) is "violated" by the
data structure, which leads me to believe that the problem might be in
whatever is parsing that response into the data structure (the server
object, I presume)... although I'm not sure what it is actually
supposed to be doing in this case, so it's hard to say

The following patch (which, given my scant knowledge, is almost
certainly wrong) makes the problem disappear for me.


  • Dave Abrahams
    Dave Abrahams

  • Dave Abrahams
    Dave Abrahams

    • assigned_to: nobody --> anadelonbrin