IMAP is fragile. The nature of the protocol is that a partial memento of the email is made available to Mail Handlers, and that calls to the underlying message object to obtain body content and attachments result in direct chatter back to the mailserver. If the mailserver decides for some reason to kill the connection the client Mail Handler gets a Folder Closed Exception, which is covered in quite a few places:

• https://jira.atlassian.com/browse/JRA-29228

Currently, what can happen is that in this situation, the mail handler cannot process the mail, because the server closed the connection. The JIRA API for Mail Handlers currently provides a TRUE (we processed it, so mark read or delete) / FALSE (we didn't process it, leave it unread). Unfortunately what seems to happen is that the 'broken' nature of this message is somehow cached via the IMAP connection, and is re-presented to mail handlers again, which breaks, again.

It may be possible to 'poke' the Mail Service back into life by revalidating its mail connection, but this may have unforeseen implications for other mail handers that could be in progress, hence this issue.

Potentially mail handlers could return 'true' to indicate that JIRA should mark the message read and delete, it's possible that would stop the same message being re-presented to the mail handler repeatedly, but could result in message loss without processing, so isnt a good option.

It would be better if a Mail Handler API enabled support for a specific Exception to indicate the nature of the problem (generally ALL related to IMAP), to drive the connection refresh, or return some kind of enumeration, which allows for more expressive hinting about what JIRA should do in the event of a failure to process a message that occurs at a protocol level.