Re: [Imap-protocol] gmail fails "tag uid fetch 123 (BODY.PEEK[2.1.1])", most others OK

--===============8838673329066939150==
Content-Type: multipart/alternative; boundary="000000000000ec2caa05835c03f1"

--000000000000ec2caa05835c03f1
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]> 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
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>

--000000000000ec2caa05835c03f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Ugh, that is probably evil to our server.=C2=A0 I do=
n&#39;t recall if we succeeded in optimizing the specific attachment reques=
ts, hopefully, otherwise we&#39;d have to reassemble the whole message, fet=
ching all 100 plus parts and then getting you what you want... With a littl=
e caching it would have to do this on every fetch.=C2=A0 That&#39;s still t=
he fallback when the individual item fetch fails for some reason (message o=
ur system didn&#39;t handle right or we have bad offsets at least)<div dir=
=3D"auto"><br></div><div dir=3D"auto">How big is the message that caching i=
t on your end is bad?<br><div dir=3D"auto"><br></div><div dir=3D"auto">Anyw=
ays, I&#39;ve forwarded to the new team.=C2=A0 Obviously it should work eve=
n if it&#39;s a lot of work on our side.=C2=A0 Is it a consistent one that =
doesn&#39;t work, or any of them?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Brandon</div></div><br><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Mon, Mar 4, 2019, 6:14 PM Gene Smith &lt;<a h=
ref=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I have been trying to fix Thunderbird so it =
properly accesses a large <br>
mailing list digest message when fetching parts only on demand (no <br>
inline display of attachments or local storage to disk of the entire <br>
mesage).<br>
<br>
The message can be found here: <br>
<a href=3D"https://bugzilla.mozilla.org/attachment.cgi?id=3D10149" rel=3D"n=
oreferrer noreferrer" target=3D"_blank">https://bugzilla.mozilla.org/attach=
ment.cgi?id=3D10149</a><br>
<br>
I have it working OK for several servers (Dovecot, MDaemon, Cyrus) but <br>
am unable to get to work with gmail.<br>
<br>
The bodystructure numbering of the message parts is like this:<br>
<br>
1 Top level message.<br>
2 Container for the 107 rfc822 message attachments<br>
2.1 The 1st message<br>
2.1.1 Body of 1st message<br>
2.2.The 2nd message<br>
2.2.1 Body of 2nd message<br>
:<br>
:<br>
2.66=C2=A0 The 66th message having attachments (example)<br>
2.66.1 Body of 66th message<br>
2.66.2 Attachment of 66th message (text)<br>
2.66.3 2nd attachment<br>
2.66.4 3rd (last) attachment of 66th message<br>
:<br>
:<br>
2.107 The 107th (last) message<br>
2.107.1 Body of 107th message<br>
<br>
Thunderbird accesses the body of an attachment like this (uid 123):<br>
<br>
tag uid fetch 123 (BODY.PEEK[2.33.1])<br>
<br>
Several servers respond OK and return the email body of the 33th <br>
attachment. But gmail responds like this:<br>
<br>
48 NO Some messages could not be FETCHed (Failure)<br>
<br>
-gene<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Imap-protocol mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"=
noreferrer">[email protected]</a><br>
<a href=3D"http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol=
" rel=3D"noreferrer noreferrer" target=3D"_blank">http://mailman13.u.washin=
gton.edu/mailman/listinfo/imap-protocol</a><br>
</blockquote></div></div></div>

--000000000000ec2caa05835c03f1--

--===============8838673329066939150==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
--===============8838673329066939150==--