[spambayes-dev] RE: [Spambayes] Delete As Spam - Doesn't
mhammond at keypoint.com.au
Thu Feb 26 22:13:38 EST 2004
> I still don't see the original message, but I have a
> suspicion that you
> are correct in guessing that this is some sort of Outlook problem.
> The error number shown in the spambayes1.log maps to
> MAPI_E_CORRUPT_DATA, and it appears that it can only appear
> as a Python
> exception if it occurs in the low-level MAPI function call to
> WrapCompressedRTFStream (inside win32all). From what I can
> gather, the
> only way that this could happen is if something is corrupted in the
> message data of that particular message. I'm afraid I can't offer any
> ideas as to what might cause that, though.
I think all of that is 100% correct.
>From the log, it appears that SpamBayes tries repeatedly to
> process the
> message but fails each time.
I'm guessing that these entries are the result of a few different
occurrences of the same failure - ie:
1) Mail comes in. SpamBayes tries to score it, but fails. Ends up
remaining in inbox, with log entry written (this log appears to have the
timer enabled, as that appears in the first traceback
2) As mail is left in the inbox, user tries 'delete as spam'. This fails,
in the same way (1) failed, so this doesn't work either, and writes a
3) Mail is *still* in the inbox - god damn stupid computers <wink> - user
goes back to (2) a few times, gives up in disgust :)
> We may need to add some additional error
> handling to prevent that. It might also be good to log a more
> descriptive message instead of just a traceback.
Yes, but we have to be careful how we do it. The error at (1) can never
display a modal error dialog (what if the mail came in overnight?). The
error at (2) should not display a dialog box for *every* error it sees - the
user may have 100 messages selected. A single error dialog may be
At the end of the day though, this error *is* special, in that it is simply
failure to get the HTML. We should handle this better. However, it is a
good reminder that random MAPI failures could occur at any place, so the
better error handling above is still needed, especially as we get more
Below is what I think the fix for this specific error is. Should I also
nuke the win32all warning, and just let the AttributeError perculate up?
Binary users will never see it.
RCS file: /cvsroot/spambayes/spambayes/Outlook2000/msgstore.py,v
retrieving revision 1.84
diff -u -r1.84 msgstore.py
--- msgstore.py 27 Feb 2004 02:57:40 -0000 1.84
+++ msgstore.py 27 Feb 2004 03:03:11 -0000
@@ -447,22 +447,22 @@
rtf_stream = mapi_object.OpenProperty(prop_tag,
+ html_stream = mapi.WrapCompressedRTFStream(rtf_stream, 0)
+ except AttributeError:
+ if not _have_complained_about_missing_rtf:
+ print "*" * 50
+ print "Sorry, but you need to update to a new win32all (158
+ print "later), so we correctly get the HTML from messages."
+ print "See http://starship.python.net/crew/mhammond/win32"
+ print "*" * 50
+ _have_complained_about_missing_rtf = True
+ return ""
+ html = mapi.RTFStreamToHTML(html_stream)
except pythoncom.com_error, details:
if not IsNotFoundCOMException(details):
print "ERROR getting RTF body", details
- html_stream = mapi.WrapCompressedRTFStream(rtf_stream, 0)
- except AttributeError:
- if not _have_complained_about_missing_rtf:
- print "*" * 50
- print "Sorry, but you need to update to a new win32all (158 or
- print "later), so we correctly get the HTML from messages."
- print "See http://starship.python.net/crew/mhammond/win32"
- print "*" * 50
- _have_complained_about_missing_rtf = True
- return ""
- html = mapi.RTFStreamToHTML(html_stream)
# html may be None if not RTF originally from HTML, but here we
# always want a string
return html or ''
More information about the spambayes-dev