IMAP4 Reader <MessageID>

Hi.

We will be changing to the new O365 Readers in due course but I came across this issue with an existing package that is meant to handle multiple filtered messages. The scenario is that there could be a few messages in the mailbox that match filter criteria and instead of having a separate Mailbox Reader for each I have a single package that gets each message and downloads their attachments separately into a distinct folder based on <MessageID>. This works well. However last Friday we had this scenario result in the attachments all being merged into a single <MessageID> folder. Upon reviewing the log today I can see that the same MessageID was used for both. I have included a redacted and trimmed log that shows this.

May I ask how the MessageID is calculated? Is it a MailBox Message Offset and thus may have some type numerical limit and in this case it has been truncated. Or is a simple incremental counter starting from 1?

Thanks in advance

Or is a simple incremental counter starting from 1?

Yes it is an incremental counter for IMAP4/POP3 connections

For Office 365 connections it is the last 64 characters of MessageID
docs.microsoft.com/en-us/graph/api/messa...h-rest-1.0&tabs=http

Thanks Mike. If it is an incremental counter then is there a reason why I ended up with a number like 27223 and that when it downloaded the second message that matched the filter it didn't increment but gave me the same <MessageID> of 27223?

Kind Regards

Hmmm. after doing some web searches I can see that there is a lot more to IMAP MessageID than I thought...

IMAP supports two methods of referencing messages, sequence numbers and UID’s. Up to now I have only used sequence numbers, in both IMAP 101 and this post. Sequence numbers are relative, in that between sessions and even during the same session, the sequence number of a message may change, whereas UID’s never change. Well, that isn’t 100 percent true, UID’s of messages may be invalidated/changed if the UIDVALIDITY folder identifier is also changed.

I think there is still some issue with how the IMPA reader is determining the message count and sequential MessageID. I will apply a few AETLE updates and see if that happens to correct the issue. Never have an issue with AETLP x32 but AETLE x64 does have this occur with one set of emails we get.

Source: Advanced IMAP

Some servers provide UID's but not all of them.
In theory, we can generate our own UIDs
But than will make it even more complicated

Again Thanks. This is more of an FYI and to keep the detail in this thread in case someone trips over it in the future,

I have attached an edited IMAP log file from AETL as it contained sensitive details. But my belief is that in this specific scenario the LAST provided Message UID is being used to populate the <MessageID> variable even though there are a number of messages to be collected.

The complete picture is that I have a RegEx Filter on the IMAP Read Action that has the potential to find more than 1 mail message at a single time. The expectation is that downstream each Message (and the attachments) will be treated individually based on the <MessageID> folder they land in . In this particular case the mail messages happen to land at about the same time from the same source but with different subjects and content. This would not be unusual. I can see in the IMAP log attached that 4 messages were present in the MailBox folder and 2 of those match the filter. But to first determine that the IMAP reader would have to FETCH each message to interrogate it to see if it matches the filter. The log shows this happen and it also shows the IMAP UID for each FETCH.

What happens is that 2 of the 4 messages match the criteria but instead of assigning either their unique UID to <MessageID> or even assigning an incremental number (eg, 1, 2) to <MessageID> - <MessageID> becomes the <UID> of the last Message FETCHED which in this case is 27327.

Because the same <MessageID> is somehow allocated to each of the filtered messages I wind up with the message attachments all landing in the same extraction folder which causes me some problems in the downstream flow.

The simplest workaround I have come up with is to change the IMAP Action Process a Single Message and then stop. As this is a scheduled Package I can do that. But it just introduces a delay in processing the messages when I could just get what I need the first time around.

Anyway, thought I would share what I found with you
cheers