> http://code.google.com/p/android/issues/detail?id=4761

Thanks for this - that's an interesting thread, and highlights just how difficult it is to write an IMAP implementation that correctly deals with every possible combination of commands the protocol allows. In this particular case, the issue is clearly a bug in my code rather than anything the Android code is doing, but it's fascinating that the approach the Android developer has taken has exposed similar problems in a wide range of other IMAP servers too.

Cheers!

-- David --

I use Mercury for three years now and use the smtp server with authenticated login to send mails. Has been working fine! 

Since a few days I have a Google phone and use the standard email client to read my IMAP mail account and to send mails. It works fine, but mails send appear to copy themselves in my send mail box. The mails are copied with the exact same date, time and content. Every once in a few days I delete hunderds of these mails and then they just appear again in growing numbers. This only happens with mails send from my Google Phone. Also mails send from another mail account with exchange does not have this problem.

I use mercury mail server. 4.72 from xampp. It runs on a Windows XP installation with all patches installed. The phone uses android 2.1 and it's the standard mail client. I usualy work with 3G connection, but the error also occurs when I use WIFI.

 Hope you hear from you guys.

Turn on session logging for MercI to capture a session and see what is happening.

The MercI session logging says:

arjan at 95.98.92.35: 690 sec. elapsed, connection closed Mon Apr 19 08:33:10 2010
Connection from 95.98.245.96, Mon Apr 19 08:45:28 2010

I've tried to use a different smtp for sending my mails, but it doesn't solve the issue. All mails that have ever been send from my Android phone keep copying themselves in my send items box. I've deleted the mails entirely from my box with send items, but they come back and start copying themselves about 40 times a day.

That is just the MercI log.

Turn on 'session logging' (checkbox on MercI config page) to capture EVERYTHING transmitted by the server & client.

Turn it off again once you have captured a session.

It only happens when your Android is connected right?

Does it happen with another IMAP client?

I have to say I saw this issue with our Macs trying to connect to send and receive email. We had one user I was trying to set up.  He has a Pegasus mail mailbox, and was using MacMail and was getting all the messages in his mailbox duplicated, triplicated, etc. every time he connected using IMAP.  Thought it might have been an issue with the VPN so that client was updated, and nothing changed.  Upgraded his Mac to the latest OS which also upgraded the email program, and we still had the same issues.  I've been reluctant to try my droid, but maybe I will to see if I can replicate your issue.  Are you using a VPN to connect to your LAN/Mercury gateway?  Have you tried something different like POP3?

Tnx for your help sofar. I tried to find the right information and copied it below. The android email app seems to have a problem with the send mails. It doesn't load any of my send items that have been send with outlook, but it does keep the items that are send from the android mail app. I reinstalled the android app and it only loads send items that have been send with the previous installation of the mail app.

 This is an excerpt from what the login when I refresh my send items. It seems to make copies of send mails every time it refreshed the send items contents.

I don't use a VPN. It connects through WIFI when I'm at home or 3G when I'm on my way.

I'll try using POP3, but the app only loads new mails. It could work, but I really want to find out why it doesn't work.

*EDIT*  tried using POP3 instead of IMAP. No more copies of send items. It's the combination of android and the usage of IMAP that creates the copies.

ahhh,,,very interesting!  You know I may try that on the Mac, I'll be it is also an issue with the IMAP protocol in Mac Mail as well.  At least you have resolved the issue for now.  Maybe there is an updated IMAP for the Android app?

It looks like there might be a bug in the MercuryI search logic (either that or the phone's SEARCH syntax is wrong, but without checking RFC3501 I can't say for sure). I'll look into this.

Incidentally... The phone is trying to work out the UID of the message it's just added to the "Sent" folder by looking for the "message-id" header after it has appended it to the folder. This (not having an easy way of working out message UIDs) is one of those annoying things about IMAP (there are many) and the phone is not behaving unreasonably by taking this approach, although it's *very* server-intensive.

Cheers!

-- David --

I've spent about an hour this afternoon looking over this issue and don't really have much to tell you.

From the session log you sent me, it seems that the Android IMAP implementation is moving messages into a folder then attempting to find their UIDs by searching for a known characteristic of the message - in this case, the message-id. Leaving aside that this is pretty load-intensive for the server (note that the search takes nearly a minute), there's nothing technically wrong with it, and based on the logs, it looks as though it should work. For some reason, though, MercuryI isn't able to match the message-id, and returns a blank search response, which presumably is what leads the Android IMAP code to upload another copy of the message.

Unfortunately, I can't duplicate this here: part of the problem is simply the density of the IMAP protocol - I can't just duplicate the commands you've sent in the log, because they require a lot of contextual knowledge. The best I've been able to do is to manually move a message into a folder then immediately initiate a search for its message-id, and that seems to work every time. Another part of the problem is that the session logs you've sent aren't complete - they don't give me a full overview of the timing of the Android app's commands. It's possible, for example, that it's searching for the message-id *before* the message is actually moved into the folder, although this doesn't seem likely.

I'll keep looking into this, but I just wanted to send an update to let you know I was working on it.

Cheers!

-- David --

http://code.google.com/p/android/issues/detail?id=4761

Just a short note to let you know that I have isolated this problem and fixed it.

For anyone interested, the problem was the fact that the search expression was enclosed in brackets... This is legal syntax, but is normally only used when NOT or OR operators are also present in the search, and my parser wasn't quite dealing with it correctly. As a side-benefit, this fix should make this type of search significantly faster.

This fix will be in the v4.73 release, which we're in the process of finalizing at present and which we hope to have out in the very near future.

Cheers!

-- David --