From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from mx1.math.uh.edu (mx1.math.uh.edu [129.7.128.32]) by inbox.vuxu.org (Postfix) with ESMTP id 6F01F2507A for ; Sun, 18 Feb 2024 19:30:47 +0100 (CET) Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rblw0-0000000FQZo-1GBO for ml@inbox.vuxu.org; Sun, 18 Feb 2024 12:30:45 -0600 Received: from lists1.math.uh.edu ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.97.1) (envelope-from ) id 1rblw0-00000000f1u-0P5A for ml@inbox.vuxu.org; Sun, 18 Feb 2024 12:30:40 -0600 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtp (Exim 4.97.1) (envelope-from ) id 1rblvy-00000000f1n-1Iu6 for ding@lists.math.uh.edu; Sun, 18 Feb 2024 12:30:38 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rblvx-0000000FQZE-1Lql for ding@lists.math.uh.edu; Sun, 18 Feb 2024 12:30:38 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References :Message-ID:Date:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=okjj+lkHpmVP9gdcbNoALyRvX1jW6ecd/xogqQ11wa4=; b=M4Gd4EQMadFXkmO/9MoGxxgQSE zJEGIVd4XDaqtlc895qhJhcE7+w4e+AT7nMAMj3Hk6Z6nqMX76fJZsPHRlp5JRd6uBUMAT70taqeY PaVoJL3HVRRNWY/jjRLAx81gC/neIrdNeOdbEhsS62WxlMgC4gROxE1Xe2ERBm0oY/8M=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rblvr-0008Vu-87 for ding@gnus.org; Sun, 18 Feb 2024 19:30:33 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rblvo-00087r-VJ for ding@gnus.org; Sun, 18 Feb 2024 19:30:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: ProtonMail Bridge Patch Date: Sun, 18 Feb 2024 10:30:21 -0800 Message-ID: <87y1bhmxqa.fsf@ericabrahamsen.net> References: <86msrzknim.fsf@kubajecminek.cz> <87frxrq84g.fsf@ericabrahamsen.net> <86cysvexqv.fsf@kubajecminek.cz> <87y1bhpt1o.fsf@ericabrahamsen.net> <87r0h94pvh.fsf@kubajecminek.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:xy0+uxz+1AoghNhcxlYmf1C4l6s= List-ID: Precedence: bulk Jakub Ječmínek writes: > "Eric Abrahamsen" writes: > >>> I might be wrong of course but I think that the latter and that there's >>> good chance sorting the headers would fix this issue. >> >> I still haven't found anything that looks like a hard requirement that >> headers be sorted, but that doesn't mean it isn't there. > > That was only my guess (based on very shallow understanding of the Gnus > internals). I can try to implement sorting and see if that helps. This > is what I found inside Gnus manual but I'm not sure if that's relevant > for this issue: > > [...] article numbers must be assigned in order of arrival in the group; > this is not necessarily the same as the date of the message. Huh. Yeah, I absolutely believe it's true, I just wish I could pinpoint where. >> I also wasn't able to find anything explicit in RFC 3501 or 9051 about >> the order of FETCH responses -- for my information, can you point me in >> the right direction? > > That's the thing. There's nothing explicit in RFC 3501 about the message > order so AFAIK the consensus is that UIDs don't have to be sorted. Oh I see. Well that's fair enough, and I don't think there's any intrinsic reason why Gnus should be imposing its internal restrictions on external servers. The assumption is just that Gnus article numbers and IMAP UIDs are the same idea -- monotonically-increasing integer identifiers that don't get reused within a group -- so we could map them one-to-one. But obviously it's more complicated than that.