"Tim Peters" <[EMAIL PROTECTED]>
writes:
> [David Abrahams]
>> Any idea why I'm not getting an answer?
>
> Perhaps because you've become the leading expert on sb_imapfilter ;-)
>
> It might help to drop the meta-discussion and start over with what the
> problem is.
Okay, here goes again. On 31 January I posted this problem that came
up for me trying to do training with sb_imapfilter with the latest
CVS:
Loading state from /usr/home/dave/hammie.new.db database
/usr/home/dave/hammie.new.db is a new database
Loading database /usr/home/dave/hammie.new.db... Done.
Account: www.stlport.com:993
Training
Training ham folder HamBox
Traceback (most recent call last):
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 1283, in
?
run()
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 1261, in
run
imap_filter.Train()
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 1004, in
Train
num_trained = folder.Train(self.classifier, is_spam)
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 888, in
Train
for msg in self:
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 799, in
__iter__
yield self[key]
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 831, in
__getitem__
data = self.imap_server.extract_fetch_data(response_data)
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", line 455, in
extract_fetch_data
msg_data = self._extract_fetch_data(msg)
File "/usr/home/dave/src/spambayes/scripts/sb_imapfilter.py", 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.
Index: sb_imapfilter.py
===================================================================
RCS file: /cvsroot/spambayes/spambayes/scripts/sb_imapfilter.py,v
retrieving revision 1.66
diff -b -d -u -b -u -r1.66 sb_imapfilter.py
--- sb_imapfilter.py 7 Apr 2006 02:36:40 -0000 1.66
+++ sb_imapfilter.py 7 Aug 2006 17:10:10 -0000
@@ -385,6 +385,7 @@
BODY_PEEK_RE = re.compile(r"(BODY\[\]) (\{[\d]+\})")
RFC822_HEADER_RE = re.compile(r"(RFC822.HEADER) (\{[\d]+\})")
UID_RE = re.compile(r"(UID) ([\d]+)")
+ UID_RE2 = re.compile(r" *(UID) ([\d]+)\)")
FETCH_RESPONSE_RE = re.compile(r"([0-9]+) \(([" + \
re.escape(FLAG_CHARS) + r"\"\{\}\(\)\\ ]*)\)?")
LITERAL_RE = re.compile(r"^\{[\d]+\}$")
@@ -406,6 +407,9 @@
data = {}
expected_literal = None
+ if self.UID_RE2.match(response[-1]):
+ response = response[:-1]
+
for part in response:
# We ignore parentheses by themselves, for convenience.
if part == ')':
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
spambayes-dev mailing list
spambayes-dev@python.org
http://mail.python.org/mailman/listinfo/spambayes-dev
