[#99002] [Ruby master Feature#17004] Provide a way for methods to omit their return value — shyouhei@...

Issue #17004 has been reported by shyouhei (Shyouhei Urabe).

21 messages 2020/07/01

[#99044] [Ruby master Bug#17007] SystemStackError when using super inside Module included and lexically inside refinement — eregontp@...

Issue #17007 has been reported by Eregon (Benoit Daloze).

7 messages 2020/07/03

[#99078] [Ruby master Feature#17016] Enumerable#scan_left — finch.parker@...

Issue #17016 has been reported by parker (Parker Finch).

42 messages 2020/07/07

[#99079] [Ruby master Bug#17017] Range#max & Range#minmax incorrectly use Float end as max — bosticko@...

Issue #17017 has been reported by sambostock (Sam Bostock).

25 messages 2020/07/07

[#99097] [Ruby master Bug#17021] "arm64" and "arm" are mixed in RbConfig on Apple silicon — watson1978@...

Issue #17021 has been reported by watson1978 (Shizuo Fujita).

9 messages 2020/07/09

[#99115] [Ruby master Bug#17023] How to prevent String memory to be relocated in ruby-ffi — larskanis@...

Issue #17023 has been reported by larskanis (Lars Kanis).

22 messages 2020/07/10

[#99156] [Ruby master Bug#17030] Enumerable#grep{_v} should be optimized for Regexp — marcandre-ruby-core@...

Issue #17030 has been reported by marcandre (Marc-Andre Lafortune).

25 messages 2020/07/13

[#99257] [Ruby master Misc#17041] DevelopersMeeting20200826Japan — mame@...

Issue #17041 has been reported by mame (Yusuke Endoh).

18 messages 2020/07/22

[#99308] [Ruby master Feature#17047] Support parameters for MAIL FROM and RCPT TO — bugs.ruby-lang.org@...

Issue #17047 has been reported by c960657 (Christian Schmidt).

11 messages 2020/07/23

[#99311] [Ruby master Bug#17048] Calling initialize_copy on live modules leads to crashes — XrXr@...

Issue #17048 has been reported by alanwu (Alan Wu).

17 messages 2020/07/24

[#99351] [Ruby master Bug#17052] Ruby with LTO enabled on {aarch64, ppc64le} architectures. — v.ondruch@...

Issue #17052 has been reported by vo.x (Vit Ondruch).

35 messages 2020/07/27

[#99375] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings — merch-redmine@...

Issue #17055 has been reported by jeremyevans0 (Jeremy Evans).

29 messages 2020/07/28

[#99391] [Ruby master Feature#17059] epoll as IO.select — dsh0416@...

Issue #17059 has been reported by dsh0416 (Delton Ding).

18 messages 2020/07/29

[#99418] [Ruby master Feature#17097] `map_min`, `map_max` — sawadatsuyoshi@...

Issue #17097 has been reported by sawa (Tsuyoshi Sawada).

11 messages 2020/07/31

[ruby-core:99316] [Ruby master Bug#17049] Net::IMAP - Handling of NOOP untagged responses sent by Zimbra

From: merch-redmine@...
Date: 2020-07-24 21:12:21 UTC
List: ruby-core #99316
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/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next