Imap search parameter arrived doesn't filter hours ?

0 votes
asked Oct 18, 2016 by pilouk (520 points)
edited Oct 18, 2016 by pilouk

I was using arrived parameter to only fetch email which arrived date are > to my last retrieved date, but i always getting the same old emails even if the lastretrievedate is superior to the email date why ? It look like it doesn't compare hour but just the day.

Note NOT working with EWS too

Applies to: Rebex Secure Mail

2 Answers

0 votes
answered Oct 19, 2016 by Lukas Pokorny (85,050 points)

DateTime-based search parameters (ImapSearchParameter.Arrived and ImapSearchParameter.Sent) ignore the time part of the DateTime value, as documented in the API reference. Only the date is used for the search.

This is actually due to a limitation in the IMAP protocol. Arrived corresponds to ON, SINCE and BEFORE IMAP search keys, and Sent corresponds to SETNON, SENTSINCE and SENTBEFORE keys. Unfortunately, all of these search keys ignore the time part - only the day is used. See IMAP protocol specification for details.

The recommended workaround for this limitation is to iterate through the search results in custom code, check the date/time values, and remove any messages whose date/time is not inside the desired interval.

0 votes
answered Oct 19, 2016 by Lukas Pokorny (85,050 points)
edited Oct 19, 2016 by Tomas Knopp

EWS protocol does not suffer from this limitation. However, please note that we still impose an equivalent in the single-parameter variants of EwsSearchParameters.Arrived and EwsSearchParameters.Sent - these are supposed to search for messages that arrived (or were sent) on the specified date (not for messages that arrived after or before the specified date/time).

In order to search for messages that arrived (or were sent) after or before the specified date/time, use the two-parameter variant of those parameters and specify null (Nothing in VB.NET) for one of the bounds. For example:

EwsSearchParameter.Arrived(DateTime.Now.AddDays(-1), null)

If this still doesn't work as expected, please let us know.

...