IMAP/POP3 inbound ignores "SEEN" flag

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1.1
  • Fix Version/s: Bug Backlog
  • Component/s: Transport: Email
  • Labels:
    None
  • Environment:

    Mule 2.1.1 IMAP transport to a Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1.

  • User impact:
    Medium
  • Similar Issues:
    None

Description

The IMAP transport does indeed mark messages as "SEEN" (when configured to do so), however it then ignores this flag and upon each subsequent poll and pulls down all messages (whether they have already been retrieved or not).

It should only retrieve "NEW" messages, at least as the default behavior.

–

The only alternative is to enable "backup", and enable delete, which will cause it to save the messages locally on the mule server. This is not a preferred solution, at least in our case, for several reasons. Most notably:

1) You can easily go into the exchange mailbox and mark a message as "unread" to get Mule to re-process it if for some reason the first processing attempt failed. [ or you can forward it to another destination for manual processing ]

2) If you are running multiple mule instances all polling the same mailbox, you don't have to figure out which mule server might have the copy of the message (nor would you have to configure a shared storage solution for old messages).

3) Lastly, new email management policies being drafted by the lawyer types require email archiving to take place only on the central exchange server. At this time there is no room for exemptions like mule folders.

  1. XML File
    imap-test-unread.xml
    15/Nov/09 04:13 PM
    2 kB
    Aleksandar Vidakovic
  2. Text File
    mule-transport-email-2.2.x-unread-messages.patch
    15/Nov/09 04:13 PM
    9 kB
    Aleksandar Vidakovic

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Rick Otten added a comment -

This appears to be true for the pop3 transport as well....

Show
Rick Otten added a comment - This appears to be true for the pop3 transport as well....
Hide
Permalink
Atte Heino added a comment -

I noticed that Mule reads the email message several times from the email box before deleting it. I tried setting threading off, but no success.

Show
Atte Heino added a comment - I noticed that Mule reads the email message several times from the email box before deleting it. I tried setting threading off, but no success.
Hide
Permalink
Aleksandar Vidakovic added a comment -

Had a quick look at that problem, because it was preventing me to use the IMAP transport.

Here is what I changed:

  • the default behaviour is now that all messages are flagged as "SEEN" instead of "DELETE"
  • there is now an additional attribute "processOnlyUnseenMessages" for the connectors; default is true

I ran the unit tests and had no failures. Additionally I integrated it quickly with one of my applications and finally the IMAP connector did what it is supposed to do (i. e. just retrieving the unread messages). You can still set "deleteReadMessages" attribute if you need that.

I just had a little doubt about one line in org.mule.transport.email.RetrieveMessageRequester.getNextMessage(Folder folder). The old code contained this:

[code]

return folder.getMessage(1);

[/code]

So the messages are retrieved one by one... ok. I replaced it with this:

[code]

Message[] messages = folder.search(new FlagTerm(new Flags(Flags.Flag.SEEN), false));

if(messages!=null && messages.length>0)

{ return messages[0]; }

else

{ return null; }

[/code]

Would be cool if someone else could have additionally a look at that. And it would be really nice if someone could include this patch (created against current 2.2.x branch) if the changes are considered OK.

Cheers,

Aleks

Show
Aleksandar Vidakovic added a comment - Had a quick look at that problem, because it was preventing me to use the IMAP transport. Here is what I changed:
  • the default behaviour is now that all messages are flagged as "SEEN" instead of "DELETE"
  • there is now an additional attribute "processOnlyUnseenMessages" for the connectors; default is true
I ran the unit tests and had no failures. Additionally I integrated it quickly with one of my applications and finally the IMAP connector did what it is supposed to do (i. e. just retrieving the unread messages). You can still set "deleteReadMessages" attribute if you need that. I just had a little doubt about one line in org.mule.transport.email.RetrieveMessageRequester.getNextMessage(Folder folder). The old code contained this: [code] return folder.getMessage(1); [/code] So the messages are retrieved one by one... ok. I replaced it with this: [code] Message[] messages = folder.search(new FlagTerm(new Flags(Flags.Flag.SEEN), false)); if(messages!=null && messages.length>0) { return messages[0]; } else { return null; } [/code] Would be cool if someone else could have additionally a look at that. And it would be really nice if someone could include this patch (created against current 2.2.x branch) if the changes are considered OK. Cheers, Aleks

People

  • Assignee:
    Unassigned
    Reporter:
    Rick Otten
Vote (3)
Watch (1)

Dates

  • Created:
    Updated: