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 9CC502ABD4 for ; Sat, 17 Feb 2024 19:06:09 +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 1rbP4i-0000000Ejwf-1bG9 for ml@inbox.vuxu.org; Sat, 17 Feb 2024 12:06:08 -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 1rbP4i-00000000cj0-0la5 for ml@inbox.vuxu.org; Sat, 17 Feb 2024 12:06:08 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtp (Exim 4.97.1) (envelope-from ) id 1rbP4g-00000000cit-21jN for ding@lists.math.uh.edu; Sat, 17 Feb 2024 12:06:06 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rbP4V-0000000Bo61-2LZD for ding@lists.math.uh.edu; Sat, 17 Feb 2024 12:06:06 -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=Ec9Qp6BHLHiLnm+oVZEgHcfWKozSse1uyR/B5Bzv5Ho=; b=iC5MUF0hQvkFJPcK8k47obMqDR Tuqv5hnt4AodRrsiP/S7GTszSoirghWNoNbRJNgrEca+lliOL0PwDRqbUCvMyvRmwAfOaoZUqDUSt y3y9kw4HWYtJjfCiqlt7p3gcFozaN9cA0M+beqDVHxegRPenDr2/m/vsm1g0a2Od0INY=; 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 1rbP47-0004ys-Ty for ding@gnus.org; Sat, 17 Feb 2024 19:05:33 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rbP46-0006gO-6N for ding@gnus.org; Sat, 17 Feb 2024 19:05:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: ProtonMail Bridge Patch Date: Sat, 17 Feb 2024 10:05:19 -0800 Message-ID: <87frxrq84g.fsf@ericabrahamsen.net> References: <86msrzknim.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:T4C92ZuZE1m1s3txNjHUrD2idkc= List-ID: Precedence: bulk Jakub Ječmínek writes: > Hello, > I'm not sure if this is the correct place to post this but I wish there > was this information somewhere like a week ago. > > I recently switched my mail provider to ProtonMail which lets you use > IMAP/SMTP protocol only if you run something called ProtonMail Bridge on > your machine. This software basically acts as a local IMAP/SMTP server > and communicates with the upstream servers in a secured fashion (or at > least this is the rationale). > > The problem is that Gnus and Gluon - IMAP server embedded inside > ProtonMail Bridge - doesn't work well together. Gnus (nnimap back end) > was acting like a lunatic and it took me a while before I found the real > reason for its behaviour. > > Gnus expects that the messages are returned from a FETCH request in a > ascending (predictable?) order but Gluon responds each time > differently. Example communication might look like this: > > Gnus: FETCH 1:3 ... > Gluon: * 3 RESPONSE ... > Gluon: * 1 RESPONSE ... > Gluon: * 2 RESPONSE ... > This is apparently a valid response according to RFC 3501. Thanks a lot for this note! I'm glad you found a solution, but if out-of-order FETCH UIDs are valid according to the RFC, Gnus should also handle that. I assume the problem is in `nnimap-transform-headers'? Nothing in there jumps out at me immediately. Or maybe the problem is that the function doesn't sort the parsed headers, and Gnus' next step expects the headers to be in sorted order? Thanks Eric