ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: merch-redmine@jeremyevans.net
To: ruby-core@ruby-lang.org
Subject: [ruby-core:99316] [Ruby master Bug#17049] Net::IMAP - Handling of NOOP untagged responses sent by Zimbra
Date: Fri, 24 Jul 2020 21:12:21 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-86711.20200724211221.42138@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17049.20200724195330.42138@ruby-lang.org

Issue #17049 has been updated by 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 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.

----------------------------------------
Bug #17049: Net::IMAP - Handling of NOOP untagged responses sent by Zimbra
https://bugs.ruby-lang.org/issues/17049#change-86711

* Author: Nestorfish (Christophe Le Roy)
* Status: Open
* Priority: Normal
* Assignee: shugo (Shugo Maeda)
* ruby -v: ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin17]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
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 we have a look to these ?



-- 
https://bugs.ruby-lang.org/

      reply	other threads:[~2020-07-24 21:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 19:53 [ruby-core:99315] [Ruby master Bug#17049] Net::IMAP - Handling of NOOP untagged responses sent by Zimbra christophe.fish
2020-07-24 21:12 ` merch-redmine [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-86711.20200724211221.42138@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).