Hi David, Xueshan, all -
As David noted, we currently have a bug opened with Apple on this issue:
Bug ID 8035310: Apple mail clients have broken UID fetch behavior
with IMAP
I'm not sure if anyone can access that directly except for our submitter. In any case, the latest update is that Apple has asked us for some additional debug data, and we're hoping to provide some additional data that demonstrates not only the UID fetch commands but also the versions of the Apple Mail clients that cause this. We believe we've seen this from these clients so far:
Mail.app
os=iPhoneOS, os-version=4.0, name=iPhone Mail
os=iPhoneOS,
os-version=3.1.3, name=iPod Mail
os=iPhoneOS,
os-version=3.2, name=iPad Mail
One of the missing pieces of data for Apple is specifically what versions of Mail.app are triggering this, so we need to review the existing data we have in order to see if we can identify. If anyone has zimbra.imap set to DEBUG and can provide BAD parse logs showing both the client and server commands, as well as the client reporting its version, this would be helpful:
zmprov aal
user@example.com
zimbra.imap
debug
I'll provide an update when we have more feedback.
Sincerely,
-thom
David,
We had same issue and we also opened a case with Zimbra. The reply is exactly what you summarized below. It's a Mac.App bug.
When we found this BAD parse error attack, we block the source IP
by route add -host <IP> reject, then later, route del -host <IP> reject
That way, at least the user can still use webmail to connect to read email.
There is no evidence of losing email or performance hit, other than the large mailboxd
logs (few million lines of errors can easily get logged in one day).
Xueshan
--
Xueshan Feng <sfeng@stanford.edu>
Technical Lead, IT Services, Stanford University
----- Original Message -----
> Hi-
> I'm a little behind in giving an update about this issue. I believe
> this is similar to the issue Dmitry is seeing (except we haven't seen
> any data loss at all associated with it), so I have added his subject
> line to the followup message.
>
> To recap, with a simple set of steps, we can cause a single MacOS X
> client (and apparently similar symptoms occur with other clients based
> on a forum posting on this), to start to DoS our Zimbra server by
> resending commands at high rates. The commands it sends results in
> tons of messages along these lines:
>
> > 2010-05-04 11:41:35,306 INFO [ImapSSLServer-634329]
> > [name=user@zimbra;mid=419;ip=ip;] imap - S: 291726.299 BAD parse
> > error: invalid message sequence number: 1:*
> > 2010-05-04 11:41:35,362 INFO [ImapSSLServer-634329]
> > [name=user@zimbra;mid=419;ip=ip;] imap - S: 291727.299 BAD parse
> > error: invalid message sequence number: 1:*
> > 2010-05-04 11:41:35,432 INFO [ImapSSLServer-634329]
> > [name=user@zimbra;mid=419;ip=ip;] imap - S: 291729.299 BAD parse
> > error: invalid message sequence number: 2:*
>
> At Thom from Zimbra's request, we opened up a case (00053746) with
> Zimbra and provided them with the diagnostic information they
> requested. Based on their analysis, here's what happened and where we
> stand. I am posting this publicly with the permission of the Zimbra
> support engineer assigned to our case:
>
> 1) This is definitely a bug in Apple's client. Zimbra says "What we're
> seeing is that once the IMAP server has told the client (Mail.app)
> that there are no more messages ("* 0 EXISTS"), no more references to
> message sequences are allowed. For some reason, Mail.app is ignoring
> this and still requesting data on messages that don't exist."
>
> 2) Zimbra has reported this to Apple both formally (bug ID #8035310,
> but I don't think you can see a bug you didn't submit) and indirectly
> through other contacts there. I have no information on when/if Apple
> plans to fix their client.
>
> 3) Zimbra has said
> a) "We're waiting to hear back from Apple before we determine what to
> do as far as a server fix. "
> b) they don't think they can fix this on the server side because "The
> only way we could really work around this is by breaking RFC 3501
> compliance, which is certainly not something we'd like to do."
>
> I'm far from an IMAP protocol expert, but I have suggested to them
> that I think there may be other possibilities for addressing this on
> the server side. For example, if you see the client doing this, drop
> the connection. In our case, we have proven that doing so causes
> Mail.app to reconnect and stop its incorrect and DoS producing
> behavior. It seems like some sort of protection on the server side
> against DoS-like behavior would be desirable.
>
> I haven't been able to get a good idea where things stand on this
> issue from Zimbra in about a week, but my last sense is that this is
> mostly going to be a waiting a game where we hope Apple fixes things
> (though if this comes up with other clients, I wonder if that will
> prompt Zimbra to take action on the server side before then).
>
> In the meantime, my current suggestion would be to either use some of
> the workarounds mentioned here (like Craig's suggestion of taking the
> account in and out of maintenance mode) or follow the advice in the
> old vaudeville routine where the patient says "Doctor, Doctor! Can you
> help me? My arm hurts terribly when I move it like this." and the
> doctor says "So, don't move it like that."
>
>
> -- dNb
--
Xueshan Feng <sfeng@stanford.edu>
Technical Lead, IT Services, Stanford University