Project

General

Profile

Bug #17049

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

Added by Nestorfish (Christophe Le Roy) 4 months ago. Updated 4 months ago.

Status:
Open
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin17]
[ruby-core:99315]

Description

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?

Updated by jeremyevans0 (Jeremy Evans) 4 months ago

  • 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.

#2

Updated by sawa (Tsuyoshi Sawada) 4 months ago

  • Description updated (diff)

Also available in: Atom PDF