From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10909 invoked from network); 19 May 2022 23:19:37 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 19 May 2022 23:19:37 -0000 Received: from localhost ([::1]:42416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nrpQc-0004Mf-VZ for ml@inbox.vuxu.org; Thu, 19 May 2022 19:19:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrpQa-0004La-1P for info-gnus-english@gnu.org; Thu, 19 May 2022 19:19:32 -0400 Received: from ciao.gmane.io ([116.202.254.214]:36152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrpQY-0006K1-Bc for info-gnus-english@gnu.org; Thu, 19 May 2022 19:19:31 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nrpQS-0001Qh-Ux for info-gnus-english@gnu.org; Fri, 20 May 2022 01:19:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: JibStyle Subject: Re: nnimap gmail "A T" and "^" not working Date: Thu, 19 May 2022 16:19:16 -0700 Message-ID: References: <877d6ire2k.fsf@ericabrahamsen.net> <87r14qo9hi.fsf@ericabrahamsen.net> <87r14qmlwj.fsf@ust.hk> <878rqym5y5.fsf@ust.hk> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (cygwin) Cancel-Lock: sha1:IXvU0J6rv+WM8BJnNCL7xg3wTE0= Received-SPF: pass client-ip=116.202.254.214; envelope-from=gegu-info-gnus-english@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" Andrew Cohen writes: > For me, the failure of "A T" is arising because the 'references header > in the emails within a thread are not right. In particular, this header > is supposed to include most of the message-ids in the thread that the > message is aware of (e.g. if its the 4th message in a chain of replies > this header should contain the message-ids of all the prior messages; if > this list of prior messages is extremely long the spec allows dropping > part of it). But for the cases where "A T" fails this header contains > only a /single/ message-id, that of the immediate prior email. This > prevents the full thread from being found. Yes, I observed this issue as well. As a workaround, pressing "A T" multiple times works to walk back up the chain, although there is a network delay. For articles where "References" header includes all previous messages, "A T" works in a single invocation as expected. > The most likely explanation is that the mailer used by the sender is not > adding the full references header. I assumed it was gmail that was > responsible, but a closer look at the messages on which "A T" fails > shows that they were all sent by the iphone mailer. So while I haven't > done any exhaustive testing, this is my current culprit. But I am > curious if others are seeing the same thing. This sounds plausible to me. I did observe that emails sent by the iPhone Mail application exhibit the headers you detailed below. However, I am not familiar with the rules of email protocol and what is considered "acceptable". > So jibstyle maybe you can help with some testing? First, for the > purposes of the test can you > 1. Set 'gnus-refer-thread-use-search to 'nil, > 2. Enter the "[Gmail]/All Mail" group and find an article late in the > thread on which you know thread referral fails to find the full thread. > Examine the headers of this article (by typing C-g when point is on the > article in the summary buffer) and see what is in the References > header? And what mailer was used to send the message? > > For example when I do this I find the headers contain > > In-Reply-To: > References: > X-Mailer: iPhone Mail (19E258) > > which shows that the References header only contains the immediately > prior email's message-id but not that of any of the other messages. Thanks for helping out here. I'm novice in email protocol. My `gnus-refer-thread-use-search' is nil. Yes, I can reproduce the iPhone specific issue you described above (see Issue1 below). In fact, I am also experiencing two additional issues (Issue2 and Issue3 below), for which I do not believe iPhone is culprit (can repro using only Gnus). To reproduce all these issues, I sent and replied to emails to myself to produce the necessary thread structures. Summary of my three separate nnimap+gmail "A T" issues: - Issue1: Grandparent not found when only one "References" entry. - Issue2: Parent from different group not found. - Issue3: Siblings and descendants not found. Reproduction steps, Issue1: --8<---------------cut here---------------start------------->8--- - FirstArticle - SecondArticle - ThirdArticle --8<---------------cut here---------------end--------------->8--- - Use iPhone Mail app with Gmail IMAP backend to produce above message thread. As Andrew suspected, ThirdArticle only includes its immediate parent (SecondArticle) in "References" header. - Read FirstArticle and SecondArticle. - In Gnus, go to "[Gmail]/All Mail" summary buffer. You should only see ThirdArticle. Now press "A T". - EXPECTED: SecondArticle and FirstArticle should appear. - ACTUAL: SecondArticle appears, but not FirstArticle. Reproduction steps, Issue2: --8<---------------cut here---------------start------------->8--- - ParentArticle - ChildArticle --8<---------------cut here---------------end--------------->8--- - Use `gnus-summary-post-news' and `gnus-summary-followup' to produce above message thread. - Copy ChildArticle to some IMAP folder e.g. "mail.testing". - In Gnus, go to "mail.testing" summary buffer. You should only see ChildArticle. Now press "A T". Also try "C-u A T" (to reverse `gnus-refer-thread-use-search'). - EXPECTED: ParentArticle should appear. - ACTUAL: ParentArticle does not appear. Reproduction steps, Issue3: --8<---------------cut here---------------start------------->8--- - RootArticle - ChildA - GrandchildA - ChildB - GrandchildB --8<---------------cut here---------------end--------------->8--- - Use `gnus-summary-post-news' and `gnus-summary-followup' to produce above message tree with two branches. - Read all articles except ChildA. - In Gnus, go to "[Gmail]/All Mail" summary buffer. You should only see ChildA. Now press "A T". - EXPECTED: RootArticle, GrandchildA, ChildB, and GrandchildB should appear. - RESULT: RootArticle appears. GrandchildA does not appear. ChildB and GrandchildB do not appear. Please let me know your thoughts on these issues, or any followup questions. In the meantime, I can find workarounds. Thank you!