Hi David,
I think the idea of performing defense measures based on certain client behavior is reasonable, and I filed an enhancement request Bug 47941 [https://bugzilla.zimbra.com/show_bug.cgi?id=47941]. When and how this gets implemented - such as dropping the IMAP connections or disabling (temporarily or permanently) user accounts - needs to be discussed further by the Engineering team, as there are complexities such as whether or not proxies are in use, how NIO_IMAP or thread pools handle connections, and what behavior (and how many actions) is considered an attack versus simply a nuisance. Defensive measures, when implemented, would likely ultimately result in loss of service for that user for at least a period of time, and one can be certain that this technique would, at times, get triggered prematurely or in unexpected or minor cases. So what is currently thought to be excessive log growth, may then turn into end user calls or complaints. The irony of using protective techniques against perceived denial of service attacks is that these techniques often seek to protect "the service" by limiting the service available to one or more source IPs or accounts, and therefore protect service by denying it; there is a careful balance here, and in some cases, these sorts of protections are best implemented by a specialty network or firewall device at the perimeter of the network.
As Xueshan and Zimbra Engineering have noted, we do not believe at this time that the BAD parse problem increases load significantly or has other significant performance or functional impact on the server other than increasing the mailbox.log size. I cannot speak for Apple, but our Engineering/QA team has tested this scenario and believes the server impact to be minimal.
Sincerely,
-thom
Hi Thom-
Thanks for the confirmation. We're certainly happy to provide any more info we can. A few followup questions, if I might:
1) has Zimbra or Apple been able to reproduce the problem following the steps we detailed? I ask because we can cause this behavior to happen every single time we try them here. As far as I know, we're using the latest shipping version of Mail.app to do so. If this is as readily reproducible outside our environment as it is here, I would think Apple could immediately see the problem in action.
2) could you speak to the question of the Zimbra server being able to mitigate bad client "attacks" (as Xueshan called them). Is that something Zimbra is considering doing? i'm wondering if it could be as simple as keeping a counter of the number of attempts to access data on messages that don't exist. If a client does that N times, you drop that one IMAP connection. I'm not claiming that this is a general protection, but I'm reasonably confident that it would immediately nip this particular problem in the bud based on the other responses in this email thread.
I'm especially interested in #2 just because it wouldn't leave my server at the mercy of another company releasing a patch in N months or the unknown number of users who don't actually apply released patches. As I understand it from various unofficial Apple sites, the next OS patch is pretty close to release (not to mention iPhone and iPad revs). This means we're in for a considerable wait before a Mail.app patch could even see the light of day.
-- dNb