SpamBayes anti-spam / Bugs / #236 imapfilter training fails

Tony Meyer - 2003-08-19

Logged In: YES
user_id=552329

I have very occasionally seen this too, but whenever I've
tried to reproduce it (to fix it) I haven't been able to. Do you
get this consistently? If you do, could you run imapfilter with
the "-i4" switch and tell me/the list what you get?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2003-08-25

Logged In: YES
user_id=844717

Here is some more using a more verbose debug:

[gaza@games gaza]$ python2.2 spambayes/imapfilter.py -v -
t -i4
SpamBayes IMAP Filter Alpha1, version 0.01 (May 2003),
using SpamBayes IMAP Filter Web Interface Alpha1, version
0.01
and engine SpamBayes Beta2, version 0.2 (July 2003).

Loading database hammie.db... Loading state from hammie.db
database
hammie.db is an existing database, with 0 spam and 0 ham
Done.
18:45.14 > FPNB1 LOGIN **** "******"
18:45.19 < FPNB1 OK LOGIN Ok.
Training
18:45.19 > FPNB2 SELECT INBOX.SB.TrainHam
18:45.19 < * FLAGS (\Draft \Answered \Flagged \Deleted
\Seen \Recent)
18:45.19 < * OK [PERMANENTFLAGS (\* \Draft \Answered
\Flagged \Deleted
\Seen)] Limited
18:45.19 < * 1 EXISTS
18:45.19 < * 0 RECENT
18:45.19 < * OK [UIDVALIDITY 1060841558] Ok
18:45.19 < FPNB2 OK [READ-WRITE] Ok
Training ham folder INBOX.SB.TrainHam
18:45.19 > FPNB3 UID SEARCH UNDELETED
18:45.19 < * SEARCH 157
18:45.19 < FPNB3 OK SEARCH done.
18:45.19 > FPNB4 UID FETCH 157 RFC822.HEADER
18:45.19 < * 1 FETCH (UID 157 RFC822.HEADER {2075}
18:45.19 read literal size 2075
18:45.19 < )
18:45.19 < FPNB4 OK FETCH completed.
18:45.20 > FPNB5 UID FETCH 157 RFC822.PEEK
18:45.20 < FPNB5 NO Error in IMAP command received by
server.
18:45.20 NO response: Error in IMAP command received by
server.
18:45.20 > FPNB6 UID FETCH 157 RFC822
18:45.20 < * 1 FETCH (UID 157 RFC822 {5442}
18:45.20 read literal size 5442
18:45.20 < )
18:45.20 < FPNB6 OK FETCH completed.
18:45.22 > FPNB7 UID FETCH 157 (FLAGS INTERNALDATE)
18:45.22 < * 1 FETCH (UID 157 FLAGS (\Seen)
INTERNALDATE "19-Aug-2003
10:07:21 -0600")
18:45.23 < FPNB7 OK FETCH completed.
18:45.24 > FPNB8 APPEND INBOX.SB.TrainHam (\Seen) "19-
Aug-2003 10:07:21
-0600" {5476}
18:45.24 < + OK
18:45.24 write literal size 5476
18:45.29 < FPNB8 OK [APPENDUID 1060841558 158] APPEND
Ok.
18:45.29 > FPNB9 UID STORE 157 +FLAGS.SILENT (\Deleted)
18:45.29 < FPNB9 OK STORE completed.
18:45.29 > FPNB10 UID SEARCH (UNDELETED HEADER X-
Spambayes-MailId
1061320725)
18:45.29 < * SEARCH
18:45.29 < * 1 FETCH (FLAGS (\Seen \Deleted))
18:45.29 < FPNB10 OK SEARCH done.
18:45.29 > FPNB11 UID SEARCH RECENT
18:45.29 < * SEARCH
18:45.29 < FPNB11 OK SEARCH done.
*.Traceback (most recent call last):
File "spambayes/imapfilter.py", line 782, in ?
run()
File "spambayes/imapfilter.py", line 768, in run
imap_filter.Train()
File "spambayes/imapfilter.py", line 594, in Train
num_ham_trained = folder.Train(self.classifier, False)
File "spambayes/imapfilter.py", line 543, in Train
msg.Save()
File "spambayes/imapfilter.py", line 365, in Save
response = imap.uid("FETCH", self.uid, "(FLAGS
INTERNALDATE)")
File "//usr/lib/python2.2/imaplib.py", line 622, in uid
typ, dat = apply(self._simple_command, (name, command)
+ args)
File "//usr/lib/python2.2/imaplib.py", line 925, in
_simple_command
return self._command_complete(name, apply
(self._command, (name,) + args))
File "//usr/lib/python2.2/imaplib.py", line 699, in _command
data = '%s %s' % (data, self._checkquote(arg))
File "//usr/lib/python2.2/imaplib.py", line 908, in _checkquote
if (arg[0],arg[-1]) in (('(',')'),('"','"')):
IndexError: string index out of range

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Meyer - 2003-09-02

Logged In: YES
user_id=552329

I think I have fixed this. If you could try out imapfilter in
1.0a5 (due 04 Sept 03) and let me know if it works, that
would be great. It should definately move the error into
smtpproxy, rather than imaplib, and it should manage to
recover from it, as well. It would be good to know that it still
acts correctly though.

(IMAP is a terrible protocol. The problem here is still the
fundamental one that you can't alter a message on the
server).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Meyer - 2003-09-02

assigned_to: nobody --> anadelonbrin

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Julien Cayzac - 2003-10-04

Logged In: YES
user_id=775162

This is not fixed in 1.0a6.
The problem is that _checkquote is invoked with a
zero-length argument, so arg[0] and arg[-1] both fail.
I tried to patch imaplib by inserting the following snippet
before that test:
if (len(arg)==0):
return arg
...then the ouput (with -i 4) is:
Password:
08:47.89 > BGIK1 LOGIN deepmind "#######"
08:49.18 < BGIK1 OK LOGIN Ok.
08:49.18 > BGIK2 SELECT
08:49.18 < BGIK2 NO Mailbox does not exist, or must be
subscribed to.
08:49.18 NO response: Mailbox does not exist, or must be
subscribed to.
Invalid response to select :
('NO', ['Mailbox does not exist, or must be subscribed to.'])

i.e., you're using select(None) at some point, which is illegal.

Hope it helps.
Julien.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Meyer - 2003-11-20

status: closed-fixed --> open
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Meyer - 2003-11-20

Logged In: YES
user_id=552329

It's been a long time (I've been away for a lot of it), but I'm
finally finding time to work on this one. I've seen something
very similar recently, which may (but may not) have been the
problem here, too.

The 'index out of range' error only occurs if the empty string
is passed (as you said) to _checkquote - IMO this is a python
bug (I've submitted a report). So, it's using select("") at
some point (not select(None), which gives a different result),
again as you said.

In the other cases I've seen, I believe this has been caused
by either (or both) the unsure or spam folder name not being
set - so it's left as "", and then messages are tried to be
moved into that, which doesn't work. Could this have been
the case here?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Meyer - 2004-03-16

status: open --> closed-out-of-date
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony Meyer - 2004-03-16

Logged In: YES
user_id=552329

No response (my long delay might have been the cause).
Closing for now, since I haven't seen this since, and lots
of other imapfilter bugs have been since fixed, which might
also fix this.

Please reopen if this still occurs.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

imapfilter training fails

Group

Searches

Help

#236 imapfilter training fails

Discussion