I recently wrote about a frustrating issue with Yahoo IMAP and I was quite surprised (and a bit embarrassed) when I actually got into contact with someone at Yahoo working on fixing it. Now I’m thinking it would be nice if I could get the same result if I write about another frustrating server issue.

But first I’ll have to quote myself from my previous blog post:

All software is buggy and it’s always a bit hypocritical for a developer to complain about bugs. I’m certainly aware that MailMate has many bugs and some of them are incredibly frustrating for some users. For those users it might be a comfort to know that an email client developer has to deal with one of the most frustrating types of bugs: IMAP server bugs.

The target of this rant is Exchange IMAP which has an annoying habit of rejecting uploaded messages without any information about why it happens. In the past I’ve seen this happen for emails with one or more very long lines. In that case, the error message is:

BAD Command Error. 10

I was able to work around it by detecting this particular response and then re-encoding its MIME parts before retrying the upload. The subject of this blog post is a slightly different error message:

BAD Command Argument Error. 11

A MailMate user reported this issue when trying to upload a sent message (created by MailMate). This message included another message forwarded as an attachment. Fortunately, I was able to reproduce the issue with an outlook.com account and I could start debugging. I simplified the message step by step and in the end it appears to require two things to happen:

  • A message including a message forwarded as an attachment.
  • The attachment includes an encoded header line which Exchange cannot parse.

Here’s an example:

From: Test@example.com
To: Test@example.com
Subject: Test message pushing Exchange to fail
Message-ID: <54259AAF-8FE0-44A4-8DCE-032F020A7C13@example.com>
Content-Type: multipart/mixed; boundary="=_MailMate_1C634E1D-F7F7-4E44-BD38-1E95A63DE5B6_="


--=_MailMate_1C634E1D-F7F7-4E44-BD38-1E95A63DE5B6_=
Content-Type: message/rfc822

Subject: =?UNKNOWN?Q?n=E9cessaire?=

Body of forwarded message.

--=_MailMate_1C634E1D-F7F7-4E44-BD38-1E95A63DE5B6_=--

The UNKNOWN charset used in the “Subject” line doesn’t make sense and was probably introduced or caused by some other buggy email software. It’s a minor issue, but apparently it’s a major issue for the Exchange IMAP implementation.

After spending a lot of time to track down the source of the problem, I now have to figure out how to work around it. You might wonder why a workaround is needed at all since the bug is clearly in the server implementation, but if I chose this path for every IMAP server bug encountered then many MailMate users would quickly consider MailMate to be unstable. Most users just need things to work. Furthermore, users might not have the option of switching to a more robust IMAP server.

The workaround I chose was to let MailMate re-encode all header lines in all MIME parts of the email before retrying the upload. This only happens for the uploaded copy. The worst part of this is that the user is not notified about the problem. (Some day I would like to add a feature which allows the user to review all the workarounds taking place while using MailMate.)

Now, I’d like to quote my previous blog post again:

An IMAP server bug can often be characterized as follows:

  • It only affects IMAP email clients and not a webmail client or some proprietary email client for the IMAP service involved.
  • It makes the email client seem like it has a bug.
  • There’s no way to report it.
  • It is probably not hard to fix.
  • It is never fixed.

Yahoo proved me wrong on the above. It’ll be interesting to see if Microsoft can do the same. In practice (for me), it doesn’t matter much because Microsoft is not in control of all installations of Exchange IMAP. Even if a bug is fixed then servers with the bug will exist many years into the future.

Some times I like to state that an email client must be able to handle any email ever generated by any kind of email software at any time of the history of emails. I should probably add that it should also be able to work around any bug that exists in any live IMAP server.

Oh, and I promise that my next blog post won’t be rant :)