I found the root cause.
The issue was because of a _activity.blk file in a user's mailbox. Any emails sent to this user while this .blk file existed caused them to sit in the SF queue with a "delivering" status. During this time, the user's mailbox was not accessible through Webmail or through an email client. The POC and MTA logs showed nothing pertaining to an issue.
I tried to rename the .blk file to something else and was told the IMAP service was using it. Checking the IMAP logs, I see thousands of errors for this user:
Code: Select all
WaitForAccessToFile: Blocking on activity file
WaitForAccessToFile: Blocking timed out on activity file
Error: Activity file access could not be obtained within the threshold of 100 seconds. Retrying.
It looks like the user may have set his email client to expunge or clean his Inbox upon exit. Nearly all of the errors in the IMAP log show the following:
Code: Select all
Expunge request on example.MAI. Failed to delete path\to\user's\deleted items folder\example.MAI. Error 2
I restarted the IMAP service and the .blk file disappeared. I could now log into the user's mailbox in Webmail and in an email client. Emails that were shown as "delivering" in the SF queues were now processed.
I believe part of the issue also may be that the user has a redirect rule on their mailbox. Because of this it seems the same emails failing in the Inbound SF queue were also failing in the Outbound SF queue and stopping the delivery of other emails. I'm not sure why this is happening now overall.
I've ran chkdsk and reported no errors. However I see the permissions for the Postoffices folder and beyond no longer have IME_STORE_GROUP in the Security tab. IME_ADMIN is okay, but IME_STORE_GROUP is nowhere to be found in the Security tab. Going to run ICACLS and re-set the permissions and see what happens.