FW: [Spambayes] Delete As Spam - Doesn't always work
Does this log file ring bells with anyone? I haven't seen errors coming out of GetHTMLFromRTFProperty before. Geoff, you may have intended to attach the email message you couldn't delete as spam, but no such attachment arrived -- just the log file. [fwd'ed with permission] [Geoff Campbell]
Hi Tim -
Attached is the latest log file (only one I could find), and also the email message that I couldn't "Delete as Spam". In trying to solve the problem, I upgraded to the latest SpamBayes version - that may have wiped out the log of when the message originally came in.
Anyway, thanks for you help.
Geoff Campbell
-----Original Message----- From: Tim Peters [mailto:tim.one@comcast.net] Sent: Thursday, February 19, 2004 1:59 PM To: geoff@controlg.com Cc: spambayes@python.org Subject: RE: [Spambayes] Delete As Spam - Doesn't always work
[Geoff Campbell]
Sometimes (very rarely) when I select an obvious spam message and "click" on "Delete As Spam", nothing happens. It seems that the message is "SpamBayes proof"! This happens once every several days, but I can't see a pattern. Using Outlook 2002 (SP-1). Would be happy
to send you a representative email.
That would be good. There's probably a helpful (to us <wink>) message in your SpamBayes log file whenever this happens. A real problem is that Outlook destroys the exact structure of incoming email, so you may not actually be able to give anyone else an email that reproduces the problem. When "nothing happens" in an otherwise-working SpamBayes, the usual cause is that the email is so badly formed (violates so many standards about how email *should* be constructed) that the SpamBayes email parser gives up trying to make any sense of it. If that's what's happening, you will find helpful (to us) information in your SpamBayes log file.
Tim - Another try to forward - I'm forwarding the "sent" item (which shows the two attachments). Maybe it's more of an "outlook" problem! Thanks - Geoff -----Original Message----- From: Tim Peters [mailto:tim.one@comcast.net] Sent: Sunday, February 22, 2004 9:19 PM To: spambayes-dev@python.org Cc: geoff@controlg.com Subject: FW: [Spambayes] Delete As Spam - Doesn't always work Does this log file ring bells with anyone? I haven't seen errors coming out of GetHTMLFromRTFProperty before. Geoff, you may have intended to attach the email message you couldn't delete as spam, but no such attachment arrived -- just the log file. [fwd'ed with permission] [Geoff Campbell]
Hi Tim -
Attached is the latest log file (only one I could find), and also the email message that I couldn't "Delete as Spam". In trying to solve the problem, I upgraded to the latest SpamBayes version - that may have wiped out the log of when the message originally came in.
Anyway, thanks for you help.
Geoff Campbell
-----Original Message----- From: Tim Peters [mailto:tim.one@comcast.net] Sent: Thursday, February 19, 2004 1:59 PM To: geoff@controlg.com Cc: spambayes@python.org Subject: RE: [Spambayes] Delete As Spam - Doesn't always work
[Geoff Campbell]
Sometimes (very rarely) when I select an obvious spam message and "click" on "Delete As Spam", nothing happens. It seems that the message is "SpamBayes proof"! This happens once every several days, but I can't see a pattern. Using Outlook 2002 (SP-1). Would be happy
to send you a representative email.
That would be good. There's probably a helpful (to us <wink>) message
in your SpamBayes log file whenever this happens. A real problem is that Outlook destroys the exact structure of incoming email, so you may not actually be able to give anyone else an email that reproduces the problem. When "nothing happens" in an otherwise-working SpamBayes,
the usual cause is that the email is so badly formed (violates so many
standards about how email *should* be constructed) that the SpamBayes email parser gives up trying to make any sense of it. If that's what's happening, you will find helpful (to us) information in your SpamBayes log file.
[Geoff Campbell]
Another try to forward - I'm forwarding the "sent" item (which shows the two attachments).
Maybe it's more of an "outlook" problem!
[Tim Peters]
Does this log file ring bells with anyone? I haven't seen errors coming out of GetHTMLFromRTFProperty before.
Geoff, you may have intended to attach the email message you couldn't delete as spam, but no such attachment arrived -- just the log file.
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.
From the log, it appears that SpamBayes tries repeatedly to process the message but fails each time. 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.
-- Kenny Pitt
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 traceback. 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 appropriate. 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 users. 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. Mark. Index: msgstore.py =================================================================== 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 @@ try: rtf_stream = mapi_object.OpenProperty(prop_tag, pythoncom.IID_IStream, 0, 0) + try: + 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) except pythoncom.com_error, details: if not IsNotFoundCOMException(details): print "ERROR getting RTF body", details return "" - try: - 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 ''
Mark Hammond wrote:
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.
[snip diff]
Looks good, +1 here. Since binary users won't see it, I don't know that the win32all warning is hurting anything. On the other hand, I think the updated builds have been out long enough that if you feel like removing it then go for it. -- Kenny Pitt
participants (4)
-
Geoff Campbell -
Kenny Pitt -
Mark Hammond -
Tim Peters