MBOX-Line: From blong at google.com  Tue Mar  5 10:55:33 2019
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Tue Mar  5 10:56:03 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123
 (BODY.PEEK[2.1.1])", most others OK
In-Reply-To: <CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
References: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
	<CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
Message-ID: <CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com>

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.

Brandon

On Tue, Mar 5, 2019 at 9:14 AM Brandon Long <blong@google.com> wrote:

> Ugh, that is probably evil to our server.  I don't recall if we succeeded
> in optimizing the specific attachment requests, hopefully, otherwise we'd
> have to reassemble the whole message, fetching all 100 plus parts and then
> getting you what you want... With a little caching it would have to do this
> on every fetch.  That's still the fallback when the individual item fetch
> fails for some reason (message our system didn't handle right or we have
> bad offsets at least)
>
> How big is the message that caching it on your end is bad?
>
> 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?
>
> Brandon
>
>
> On Mon, Mar 4, 2019, 6:14 PM Gene Smith <gds@chartertn.net> wrote:
>
>> I have been trying to fix Thunderbird so it properly accesses a large
>> mailing list digest message when fetching parts only on demand (no
>> inline display of attachments or local storage to disk of the entire
>> mesage).
>>
>> The message can be found here:
>> https://bugzilla.mozilla.org/attachment.cgi?id=10149
>>
>> I have it working OK for several servers (Dovecot, MDaemon, Cyrus) but
>> am unable to get to work with gmail.
>>
>> The bodystructure numbering of the message parts is like this:
>>
>> 1 Top level message.
>> 2 Container for the 107 rfc822 message attachments
>> 2.1 The 1st message
>> 2.1.1 Body of 1st message
>> 2.2.The 2nd message
>> 2.2.1 Body of 2nd message
>> :
>> :
>> 2.66  The 66th message having attachments (example)
>> 2.66.1 Body of 66th message
>> 2.66.2 Attachment of 66th message (text)
>> 2.66.3 2nd attachment
>> 2.66.4 3rd (last) attachment of 66th message
>> :
>> :
>> 2.107 The 107th (last) message
>> 2.107.1 Body of 107th message
>>
>> Thunderbird accesses the body of an attachment like this (uid 123):
>>
>> tag uid fetch 123 (BODY.PEEK[2.33.1])
>>
>> Several servers respond OK and return the email body of the 33th
>> attachment. But gmail responds like this:
>>
>> 48 NO Some messages could not be FETCHed (Failure)
>>
>> -gene
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Imap-protocol mailing list
>> Imap-protocol@u.washington.edu
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190305/3bfc6963/attachment.html>
