Mule
  1. Mule
  2. MULE-4003

IMAP/POP3 inbound ignores "SEEN" flag

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.1
    • Fix Version/s: None
    • 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:
      MULE-3925Add failOnTimeout flag to the inbound Aggregator.
      MULE-5481Mail inbound - AddressException
      MULE-4368Payload set on a quartz inbound endpoint is ignored
      MULE-3255Inbound and response transformers configured on CXF endpoints are ignored
      MULE-441"transformers" property is ignored for an outgoing endpoint
      MULE-6870HTTP Patch body is ignored
      MULE-6053CxfOutboundMessageProcessor "operation" property is ignored
      MULE-183Add a stopProcessing flag on the response router
      MULE-7036QueuedAsynchronousProcessingStrategy ignores queue store configuration
      MULE-3299The Splitter router has a flag called "honorSynchronicity" I think this can be removed

      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. imap-test-unread.xml
        2 kB
        Aleksandar Vidakovic
      2. mule-transport-email-2.2.x-unread-messages.patch
        9 kB
        Aleksandar Vidakovic

        Activity

        Hide
        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
        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
        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
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development