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=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10562 invoked from network); 9 Oct 2021 14:28:14 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 9 Oct 2021 14:28:14 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 4ess; Sat Oct 9 10:23:13 -0400 2021 Received: from abbatoir.myfiosgateway.com (pool-74-108-56-225.nycmny.fios.verizon.net [74.108.56.225]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id d2deab4a (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Sat, 9 Oct 2021 07:22:56 -0700 (PDT) Message-ID: To: 9front@9front.org Date: Sat, 09 Oct 2021 10:22:55 -0400 From: ori@eigenstate.org In-Reply-To: <405ABA392F41295D7D6361D94B2A8E08@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: progressive SSL over ORM metadata app Subject: Re: [9front] upas/fs: handle outlook's quirks Reply-To: 9front@9front.org Precedence: bulk Quoth risto.salminen@gmx.com: > The handling of a message larger than expected works > exactly in the same way as the current quirk for Gmail. > When requesting the last chunk of a message, upas/fs > increases the chunk length, so that hopefully the whole > message will be read, and then afterwards also adjusts > its internal notion of the message length accordingly. > > To benefit from this patch, the desired mailbox indices > have to be recreated, by manually removing them, so that > upas/fs will then create them automatically. Otherwise, > things will continue to work as before. > > Would this be useful for the broader audience? Yes, though I'm probably going to see if I can make sense of some other imap implementations and see how fetching is handled differently there before I commit this. Give me a couple of days.