In the application I'm working on, there is a function that connects with a mail server via IMAP using JavaMail. One of our clients had the following stack trace:
javax.mail.MessagingException: A13 BAD Command Argument Error. 11;
nested exception is:
com.sun.mail.iap.BadCommandException: A13 BAD Command Argument Error. 11
at com.sun.mail.imap.IMAPMessage.setFlags(IMAPMessage.java:847)
at javax.mail.Message.setFlag(Message.java:565) ...
Now, what it was trying to do is the following:
messages[i].setFlag(Flags.Flag.RECENT, false);
Where messages[i] is a javax.mail.Message.
Now, this error has never occurred to any of our clients who use Exchange Server 2003 and since this client is using Exchange Server 2007 I'm presuming it has something to do with it (bug?). I also made sure they updated it to the latest service pack and rollup update (Service pack 1 update 8 as of this writing) and the latest JavaMail (1.4.2 as of this writing) and it had no affect. My question is, is this something I have to wait for Microsoft to fix? Is there a workaround I can employ?
For the record, the reason why I am setting the recent flag to false is so that the given message will not be processed again in a second pass (i.e. it only processes recent or new messages).
My reading of the API for Flags.Flag.RECENT indicates that it's read-only from a client app. The folder implementation should set it when the "message is new to this folder". So unless you're writing a Folder implementation you shouldn't be modifying this flag.
That leaves one to wonder why your other clients don't get the error. Perhaps it's treated as a NOOP in some cases? Perhaps there is something special about this particular client's folder? Perhaps a shared folder, or a folder the user has read-access too? I'm not equipped to ponder the mysteries of the Exchange message store.