Re: [Imap-protocol] gmail fails "tag uid fetch 123 (BODY.PEEK[2.1.1])", most others OK
Brandon Long <[email protected]> Tue, 5 Mar 2019 10:55:33 -0800
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com> |
--===============8726061299259631914== Content-Type: multipart/alternative; boundary="000000000000c3fc6a05835d6b63" --000000000000c3fc6a05835d6b63 Content-Type: text/plain; charset="UTF-8" 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 <[email protected]> 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 <[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 >> > --000000000000c3fc6a05835d6b63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Also interesting if it can fetch the full message, since t= hat again might require a lot of individual fetches to reassemble, which mi= ght time out if we don't handle that correctly.<div><br></div><div>Bran= don</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma= il_attr">On Tue, Mar 5, 2019 at 9:14 AM Brandon Long <<a href=3D"mailto:= [email protected]">[email protected]</a>> wrote:<br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div>Ugh, that is proba= bly evil to our server.=C2=A0 I don't recall if we succeeded in optimiz= ing 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 eve= ry fetch.=C2=A0 That's still the fallback when the individual item fetc= h fails for some reason (message our system didn't handle right or we h= ave bad offsets at least)<div dir=3D"auto"><br></div><div dir=3D"auto">How = big is the message that caching it on your end is bad?<br><div dir=3D"auto"= ><br></div><div dir=3D"auto">Anyways, I've forwarded to the new team.= =C2=A0 Obviously it should work even if it's a lot of work on our side.= =C2=A0 Is it a consistent one that doesn't work, or any of them?</div><= div dir=3D"auto"><br></div><div dir=3D"auto">Brandon</div></div><br><br><di= v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 4= , 2019, 6:14 PM Gene Smith <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:<br></div><blockquote class=3D"= gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= 4,204,204);padding-left:1ex">I have been trying to fix Thunderbird so it pr= operly 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]" rel=3D"noreferrer" target= =3D"_blank">[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> </blockquote></div> --000000000000c3fc6a05835d6b63-- --===============8726061299259631914== 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 --===============8726061299259631914==--