Johannes Berg wrote:
Hi,
However, I know from looking at the dspam system.log file, the retraining actually happens - so it -does- appear to be calling dspam. It appears that the 'move' operation fails.
Plugin debug log when I attempt to move a message: Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_unsure(SPAM): 0 Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_trash(INBOX): 0 Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_trash(SPAM): 0 Jun 13 09:29:07 stelleri imap: antispam: mail copy: from trash: 0, to trash: 0 Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_spam(INBOX): 0 Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_spam(SPAM): 1 Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_unsure(INBOX): 0 Jun 13 09:29:07 stelleri imap: antispam: mail copy: src spam: 0, dst spam: 1, src unsure: 0 Jun 13 09:29:07 stelleri imap: antispam: /usr/local/bin/dspam --source=error --class=spam --signature=4a339984859385209328925 --deliver= --user frysco
Associated log from dspam system.log: 1244903347 M <None Specified> 4a339984859385209328925 <None Specified> 0.066815 frysco Retrained
I have no idea what's going on, obviously, but please verify that the above dspam command line
- exits with exit code 0
- doesn't print anything to stderr
Both of these are taken by the plugin as an indication that something went wrong, because dspam's error reporting was _severely_ lacking at the time I wrote the plugin. It might have improved in the meantime, I have no idea.
It certainly seems to be the 'verbose debug' information that DSpam prints to stderr that triggers this.
After testing with the patches from Marcin Rzepecki and Harlan Stenn, I managed completely disabled these kind of lines from being sent:
Jun 13 15:35:18 stelleri imap: antispam: error: dspam returned <57397: [06/13/2009 15:35:18] query error: VERBOSE DEBUG (INFO ONLY - NOT AN ERROR): see sql.errors for more details >
I then put in the unaltered FreeBSD ports version of the plugin, and no longer got the "Failed to call dspam" messages.
Since these messages - even though non-zero and stating that they aren't an error - are just informational, I'd think that it might be an idea to have the plugin detect and ignore that.
Turning on DSpam debugging should not (I should think) break the plugin from working.
Thanks, -jcd