On Fri, 2007-07-20 at 13:43 +0200, Paul J Stevens wrote: > Aleksander Kamenik wrote: > > > >> I'm setting this report to resolved. Please re-open if that turns out > >> to be > >> premature at this point. > > > > I confirm that the patch fixed this issue. > > > > Although, all messages of "this" kind that have been received from at > > least 2.2.5rc2 up to 2.2.6rc1 are broken. A pity this wasn't an IMAP issue. > > > > Thanks, > > > > It was an IMAP issue! > > Before this fix, an X-DBMail-Physmessage-ID header was added during message > retrieval. (before 2.2.5-rc1 this was added during insertion) > > For POP3 or export this as not a problem. The header was added, and that was > that. > > But for IMAP FETCH (as used for imapsync, forwarding, etc) it was a problem > if > the client retrieved the exact amount of octets specified in the RFC822.SIZE > response. If the client stopped after retrieving the exact amount of data > specified, the message would be incomplete because the message length was > changed on the fly. Clients like imapsync or fetchmail would simply retrieve > the > entire message (without exactly specifying the amount of octets they want). > Those clients had been complaining about size mismatches. But TB would be > very > precise in requesting parts of the message, until it was satisfied it had > retrieved the amount specified in the RFC822.SIZE response. > > Am I making sense yet?
Well done! That header has been in there so long I definitely would not have suspected it as the problem. Aaron _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
