[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spambayes-bugs
Subject:    [spambayes-bugs] [ spambayes-Bugs-1071319 ] Outlook plug in for
From:       noreply () sourceforge ! net (SourceForge ! net)
Date:       2004-11-26 4:15:32
Message-ID: E1CXWa0-00046i-6x () sc8-sf-web4 ! sourceforge ! net
[Download RAW message or body]

Bugs item #1071319, was opened at 2004-11-23 11:15
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498103&aid=1071319&group_id=61702

Category: Outlook
Group: Binary 1.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Keegan Staker (kstaker)
>Assigned to: Tony Meyer (anadelonbrin)
Summary: Outlook plug in for IMAP boxes

Initial Comment:
I know similar problems have been listed, however i dont 
believe they were addressed, nor do i believe the 
previous poster was clear.  

When using the oulook plug in to monitor IMAP boxes in 
Outlook, a couple undesirable effects occur that have 
people angry at me.  

First: 
If a message is placed in "Junk Suspects" and a user 
attempts to "Recover from Spam" the message is 
returned to the local store inbox instead of the IMAP box 
from which it came.  I have read that this occurs 
because the plug-in cannot actually modify the message 
to tell where it came from, and thus where to put it if 
recovered.

My suggested workaround is the following:  Add an IMAP 
Recovery option that allows the user to select which 
folder recovered messages are returned to.  Seems 
simple enough and would result in less "lost messages".

Second:
As a workaround to the above problem, my users drag 
messages from the "Suspects" folder back to the Inbox, 
since hitting the recover button moves those messages 
to the wrong folder.  This is a fine solution if the 
message has been marked as read, however if the 
message is marked as unread, then within a few seconds 
SpamBayes evaluates the message again and moves it 
to the Suspects folder again.  Again, there is a 
workaround, which is that the messages must be marked 
as unread before manually dragging them back.  The 
result however, is a marked decrease in usability and 
simplicity.

Of course my suggestion to this is to resolve the 
underlying issue stated above.

I appreciate your time and this wonderful product.

Keegan

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-11-26 16:15

Message:
Logged In: YES 
user_id=552329

The first problem is now fixed in CVS, as we record this
information elsewhere and so recovering on IMAP should work
just like it does everywhere else.  However, this change
relies on other changes that are too major to go in a bugfix
release, so this won't appear until 1.1 (rather than 1.0.2).
 That'll probably be early next year for a1 and maybe March
for a final release.  However, a new option would also fail
to make it into a bugfix release.

The second problem occurs (I believe) because IMAP actually
creates a new message when you drag one in - it doesn't
actually move the message (you can't move a message with
IMAP).  So SpamBayes has no way of telling that it's the
same message, so treats it as new.  Working around this
would be very difficult, and since fixing the other problem
removes the need, I'll leave this one alone.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498103&aid=1071319&group_id=61702

[prev in list] [next in list] [prev in thread] [next in thread]