Announcement Announcement Module
No announcement yet.
Polling email sets task flag in Outlook, why? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Polling email sets task flag in Outlook, why?


    I'm new to SI so I could be missing something. That being said here is the issue I am experiencing. I have set up an inbound-channel-adapter to poll for email over an IMAP uri. When I start up the app and it reads the unread emails it sets a task flag on the messages it has read. Note, this is not behavior I want nor do I understand why this is occurring. Has anyone had this experience before? Do you know what could be causing it?


  • #2
    It's not clear which flag you are talking about.

    If you mean the "SEEN" flag, there's an attribute on the adapter "should-mark-messages-as-read" which defaults to true.

    Set it to "false" to not set this flag.

    Also, for mail servers that don't support the "RECENT" flag, the adapter sets a flag to mark messages it has already retrieved so it doesn't keep getting the same message(s). If the server supports user-defined flags, the flag is "spring-integration-mail-adapter"; if it doesn't support user flags, it sets the FLAGGED flag. In either case, this is used by the DefaultSearchTermStrategy to avoid getting the messages next time.

    Can you explain exactly what your issue is?


    • #3

      The behavior I am seeing is that after the email is read there is a "to-do task" set on the message in outlook. Here are the settings I have configured for the adapter.
      	<int-mail:inbound-channel-adapter id="poll-for-email"
      	                                  store-uri="imaps://[email protected]/INBOX"
      	                                  should-delete-messages="false" should-mark-messages-as-read="true">
      		<int:poller fixed-rate="60000"/>
      I have obfuscated the account info but this is all that I have configured for the adapter. Since this is configured to pull form an exchange server I suppose it has something to do with what you mention about it setting the "FLAGGED" flag.

      Any help is appreciated.

      Last edited by Gary Russell; Mar 29th, 2013, 10:09 AM.


      • #4
        When posting code and config, please use [ code ] ... [ /code ] tags (no spaces in brackets). I edited your post.

        I am guessing you are right; from the RFC...

        Message is "flagged" for urgent/special attention
        ... so maybe Exchange puts a "TODO" on the message in that case.

        I don't have access to an Exchange server (I assume you are using Exchange given you are using Outlook).

        As I said, this is only set if the server supports neither /Recent, nor user defined flags. I don't know if Exchange is in that category.

        Unfortunately, there is no way to stop the flag being set in this case (unless you subclass ImapMailReceiver and override setAdditionalFlags() to remove it - that method is called after it's set).

        However, the default search term DOES omit \Seen messages so, at least with your current configuration (marking messages as read), we really don't need to set the \Flagged flag - but it would definitely cause problems with getting repeated messages if they are not marked as read.

        You can verify the behavior by setting the debug property in your JavaMail properties...

        <prop key="mail.debug">true</prop>
        ...and you'll see all the IMAP protocol in the console.

        Unfortunately, it's not particularly easy right now to inject a customized ImapMailReceiver (but it is possible and I can help you with that).

        I see a couple of JIRA issues coming out of this discussion.

        1. Provide an easier mechanism to inject a custom MailReader into the adapter (allowing customization of behavior such as this).
        2. Provide an option to suppress setting the \Flagged flag (when using servers with less than first class IMAP support). With a caveat that either read messages must be marked as such or the user needs to provide some other search term strategy to prevent retrieving the same messages.

        Please go ahead and create these if you wish...