Bug #17049: Net::IMAP - Handling of NOOP untagged responses sent by Zimbra

• Status: Closed
• Assignee: shugo (Shugo Maeda)
• Target version: -
• ruby -v: ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin17]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN

[Nestorfish (Christophe Le Roy)]

Zimbra server sends invalid untagged responses to prevent some clients from disconnecting during long-running requests.
As they are invalid, they raise an exception in Net::IMAP, while they could be clearly identified and safely ignored.

I have opened an issue on net-imap GitHub repository along with a pull request (https://github.com/ruby/net-imap/issues/2 and https://github.com/ruby/net-imap/pull/3), but it seems I should have reported the issue here.

Can you have a look at these?

[jeremyevans0 (Jeremy Evans)]

• Assignee set to shugo (Shugo Maeda)

Per RFC 3501 Section 7: The client MUST be prepared to accept any response at all times. Arguably, raising an exception is not proper preparation. Looking at the formal grammar, it does not appear that * NOOP is a valid server response (though * NO OP would be), so Zimbra's behavior does appear to go against the standard. I think if we were going to fix this in net/imap, we should not make this specific to * NOOP, we should handle any unrecognized untagged response the same way. However, @shugo (Shugo Maeda) is the maintainer of net/imap, so the behavior is up to him.

It looks like Zimbra's bug tracker for the IMAP component is: https://bugzilla.zimbra.com/buglist.cgi?component=IMAP%2FPOP%20Server&product=ZCS&resolution=--- I recommend you report the issue there. You could also create a patch and add it as a pull request to https://github.com/Zimbra/zm-mailbox/pulls. However, it appears the behavior in Zimbra is deliberate to keep connections active, so you may encounter some resistance. According to RFC 3501, sending NOOP to keeping connections open is the job of the client (NOOP requests), it's not the job of the server.

[sawa (Tsuyoshi Sawada)]

• Description updated (diff)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed