95 lines
3.2 KiB
Plaintext
95 lines
3.2 KiB
Plaintext
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>
|