This article may explain many of my problems which (hopefully) are now resolved after all users with these devices have upgraded to the latest ios.

http://www.zdnet.com/ios-6-1-banned-from-corporate-servers-due-to-exchange-snafu-updated-7000011064/

Bottom line is that Microsoft were advising Exchange administrators to block them !

Ios mail was seriously misbehaving with Mercury.

Hi All,

I'm having a terrible time with mercury and my imap clients. For some reason mercury is creating and leaving a zero byte _inbox_.pnm file in my users mercury mail folder.

When this happens, the client does not get any update to their inbox (e.g. new mail not received at client). Once it happens to one mailbox, each other  imap client that makes a connection seems to end up in the same state.

Their is no rhyme or reason to when this happens. I have excluded the mail folders from av scanning. Can't see anything obvious in the imap logs / session logs.

Only way I can resolve is to shutdown mercury, delete all the invalid _inbox_.pnm files, mailbox.lck files, restart mercury.

Becoming a real pain, clients are mainly Ipad / Iphone devices.

Can anyone help ?

Cheers,

Dougie.

Try turning on verbose logging in MercI to see if there is any clues in the logs.

Note: IMAP is very noisy protocol and there will be lots of output.

I've been doing this, problem is, I don't know what I'm looking for. 

There are no references to _inbox_.pnm in any of the logs.

_inbox_.pnm is, as you probably know, a text file containing a list of messages in the inbox, that is created and maintained by Mercury. It should be updated automatically in the background when the contents of the inbox changes, so there is no direct reference to it in any logs. What you should look for in the MercuryI logs is any error or specific event that happens approximately at the same time as _inbox_.pnm errors occur.

Still, as this isn't a common problem, I would say it's more likely to be caused by something else than IMAP commands. Double-check that mailbox directories in fact are excluded from all realtime antivirus scanning and any other antimalware software that might be running, check the NTFS status with chkdsk, confirm that the disk isn't nearly full or heavily fragmented, and switch off file indexing in Windows in case it's active. As IMAP can use a lot of memory if there are many concurrent users it might be a good idea to check that there is enough RAM available as well.

/Rolf 

Thanks Rolf, all the above has been fully checked.

I have reasons to suspect It may be a firewall issue. Apparently all is well when running on the internal network, but I only have port 143 open for Imap at my external firewall. 

This appears to be where the problem stems. When an Ipad client is offsite and sends an email, the problem appears to be when the Ipad updates the server 'sent messages' folder.

I've been using wireshark / imap logs to come to this conclusion.

Can you tell me which other ports I should have open to make these ipads function correctly ?

IMAP will only need port 143 to be open to work, but it could be that some antimalware program is monitoring that port and causes lockups. If a sub-folder, for instance the one for sent messages, contains extremely many messages that could perhaps lead to problems, but I don't see any connection to the _inbox_.pnm file unless it would crash the IMAP module altogether. You could try to increase the TCP/IP timeout for IMAP considerably and see if that makes any difference, though. Make sure that you run the current version of Mercury (1.74) as well.

/Rolf 

[quote user="Rolf Lindby"]

IMAP will only need port 143 to be open to work, but it could be that some antimalware program is monitoring that port and causes lockups. If a sub-folder, for instance the one for sent messages, contains extremely many messages that could perhaps lead to problems, but I don't see any connection to the _inbox_.pnm file unless it would crash the IMAP module altogether. You could try to increase the TCP/IP timeout for IMAP considerably and see if that makes any difference, though. Make sure that you run the current version of Mercury (1.74) as well.

/Rolf 

[/quote]

Not correct Rolf. Have a look here :-

http://support.apple.com/kb/ts1629

Appear to have problem solved.

I have opened 3 more ports on external net traffic to my domain, will post more specifics soon but port 587 is my favourite. :-

Message Submission for Mail (Authenticated SMTP) :- Mail (for sending mail), iCloud Mail (SMTP authentication)

The issue only arises when the remote client is trying to update the sent messages folder. (Causes serious issues in the configured 'scratch' folder)

Dougie.

[quote user="ecosse"][quote user="Rolf Lindby"]

IMAP will only need port 143 to be open to work, but it could be that some antimalware program is monitoring that port and causes lockups. If a sub-folder, for instance the one for sent messages, contains extremely many messages that could perhaps lead to problems, but I don't see any connection to the _inbox_.pnm file unless it would crash the IMAP module altogether. You could try to increase the TCP/IP timeout for IMAP considerably and see if that makes any difference, though. Make sure that you run the current version of Mercury (1.74) as well.

/Rolf 

[/quote]

Not correct Rolf. Have a look here :-

http://support.apple.com/kb/ts1629

Appear to have problem solved.

I have opened 3 more ports on external net traffic to my domain, will post more specifics soon but port 587 is my favourite. :-

Message Submission for Mail (Authenticated SMTP) :- Mail (for sending mail), iCloud Mail (SMTP authentication)

The issue only arises when the remote client is trying to update the sent messages folder. (Causes serious issues in the configured 'scratch' folder)

Dougie.

[/quote]

Found the definitive apple document :-  

http://support.apple.com/kb/HT1421

iOS: Setting up a corporate email server

Summary

This article explains the key steps for setting up a corporate mail server which can be accessed by an iOS device. These key steps will need to be completed by the IT support team or network administrator to enable email access.
Products Affected

iPad, iPhone, iPod touch, Verisign

For non-Exchange mail server configurations, or for Exchange server access via IMAP, use the following settings to enable secure iOS access: 
Step 1

Open port 993 to allow email to be received through the firewall.

The proxy server must be set to IMAP over SSL only. SSL ensures that mail is securely encrypted during wireless transmission.

Step 2

As a best practice and for additional security protection, install a digital certificate on the server from a trusted certificate authority such as Verisign.

Installing a certificate from a certificate authority (CA) is an important step in ensuring that your proxy server is a trusted entity within your corporate infrastructure.



Step 3

Either port 587, 465, or 25 must be opened to allow email to be sent from iOS.
Additional Information

When sending a message, iOS automatically checks first for port 587, then 465, and then 25. Apple recommends opening 587 as the most reliable, secure port because it requires user authentication. Port 25 is considered to be the least secure because it's been around the longest and is subject to more attacks by hackers. It's also the port that some ISPs block by default to prevent unsolicited spam.

_____________________________________________________________________________

Problem must be a bug in IOS as it never touches our port 25 when updating sent messages. 

p.s. What corporate does not have port 25 open if hosting their own smtp ?

Sorry if this wasn't clear, but all the same I have to insist that IMAP only needs port 143 to work. To use SSL protection for IMAP port 993 must be open as well (and SSL must be enabled in Mercury), but that's not a requirement for IMAP as such. If the device is set to connect only if SSL is available and port 993 is closed the _inbox_.pnm file would never be modified as there simply wouldn't be any IMAP session opened to that mailbox.

Port 25 and 587 are commonly used for SMTP (port 465 was for the now deprecated SMTPS protocol). They are not used for IMAP, but to have a fully functional mail server SMTP and port 25 are pretty much a must.

You can find most of the relevant RFCs here: http://community.pmail.com/forums/26/ShowForum.aspx

Coming back to the initial question the iOS device would presumably do two things when sending a message: start SMTP transfer for sending it to the recipient(s), and issue IMAP commands to place a copy of the message in the sender's Sent folder. If the IMAP session is interrupted it should be possible to see that in a session log from MercuryI.

/Rolf