wasm-demo/demo/ermis-f/imap-protocol/cur/1600094973.22518.mbox:2,S

39 lines
1.6 KiB
Plaintext

MBOX-Line: From gds at chartertn.net Tue Mar 5 11:46:44 2019
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Tue Mar 5 11:47:35 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123
(BODY.PEEK[2.1.1])", most others OK
In-Reply-To: <CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com>
References: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
<CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
<CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com>
Message-ID: <36148fc1-25ba-b3bc-b34f-1da2a4bde55c@chartertn.net>
On 3/5/19 1:55 PM, Brandon Long wrote:
> Also interesting if it can fetch the full message, since that again
> might require a lot of individual fetches to reassemble, which might
> time out if we don't handle that correctly.
I don't see a problem when the whole message is fetched. That's the
default tb mode and the message is stored/cached to a disk file.
> How big is the message that caching it on your end is bad?
This message itself is just 350K. But if you configure the folder so
that the message is only cached to memory (not to a file) and not
showing attachments inline, then tb fetches attachment on demand when
clicked using the part number.
>
> Anyways, I've forwarded to the new team.? Obviously it should work
> even if it's a lot of work on our side.? Is it a consistent one that
> doesn't work, or any of them?
I haven't tested tb a lot with gmail using fetch by parts, mostly
Dovecot. I'll let you know if I see other problems.
I hope I understand and answered your questions. Thanks.