When the client fetches new items from the server a 'Transmission Error' dialog is presented with the following error:
"The connection to server was interrupted while transferring data. Please click off and on the folder to ensure that the folder is updated from the server".
Usually the cause of the transmission error is related to an external Firewall device (Router Firewall also) filtering the IMAP packet data and dropping the connection. To determine if this is the case the first step is to anaylze the MailEnable Connector for Microsoft Outlook log file. Details on how to enable the log file is explained in the following article: https://www.mailenable.com/kb/content/article.asp?ID=me020589
Open the connectors log file and search for the following error:
Request failed waiting for response: [4poiu X-MSGID-FETCH messageID.mai,
messageID.mai (X-ME-MSGID X-ME-MODIFIED X-ME-SUBJECT X-ME-ATTACHMENTS FLAGS
]. Socket  returned error -1 (10054).
The 10054 error indicates that there was a disconnection whilst the client was fetching data from the server.
The first step is to test and locate who was responsible for the connection drop. To do this we perform a telnet test locally on the server (bypassing any firewall or gateway device) and from the client machine. The requires issuing the same fetch command where the error is returned in the connector log file.
telnet localhost 143
* OK IMAP4rev1 server ready at 05/16/18 10:45:20
1 login test pass
1 OK LOGIN completed
1 select inbox
* FLAGS (\Deleted \Seen \Answered \Flagged \Draft $Forwarded $IsMailingList)
* 0 EXISTS
* 0 RECENT
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Flagged \Draft $Forwarded $IsMai
* OK [UIDNEXT 43]
* OK [UIDVALIDITY 1524706150] UIDs valid
1 OK [READ-WRITE] SELECT completed
1 X-MSGID-FETCH messageID.mai, messageID.mai (X-ME-MSGID X-ME-MODIFIED X-ME-SUBJ
ECT X-ME-ATTACHMENTS FLAGS BODY)
1 OK FETCH command completed [SyncKey:1525827540]
The above test is just an example and you need to substitute the commands with the same values in the X-MSGID-FETCH from the log file. If the test succeeds but fails from the client machine and returns a 'Connection Lost" after issuing the fetch then this would indicate that an external device is filtering the data and dropping the connection.
The next step is to consult within the documentation for the firewall/gateway to review log files or contact the manufacturers support contacts in diagnosing the problem.
A workaround is to configure the MailEnable IMAP service to listen on alternative IMAP port. I.e. 144. The reason for this is so that the firewall does not recognise the alternative port as an IMAP port and not filter the data.
For further details please see:
https://www.mailenable.com/documentation/10.0/Standard/webframe.html#IMAP_General.html - Also listen on alternate port
You will also need to add rules for the port in your firewall or router port forwarding settings. Once you have set this up configure the MailEnable Connector for Outlook to connect via IMAP on the alternative port.
While the above is a workaround to allow clients to connect and sync, we strongly recommend looking into your firewall configuration and documentation to see if there are options to disable IMAP filtering or filtering rules. One device that we are aware of that filters IMAP packet data is SonicWall Firewall.
|Class:||PRB: Product Problem or Issue|
|Revised:||Wednesday, May 16, 2018|