[dovecot] big mail problems..
Attachments, large mails & etc. seem to have problems with my installations of dovecot. As we know, Mozilla likes to take it's mail in chunks, and after Mozilla, (or Mail.app, it likes to do this, too) takes its first chunk, it doesn't start getting the rest, even though ethereal tells me that dovecot OK'ed the 10K chunk.
9 UID fetch 4 (UID RFC822.SIZE BODY[]<0.10240>)
- 4 FETCH (UID 4 RFC822.SIZE 3958069 BODY[]<0> {3958069} <snip> 9 OK Fetch completed.
Nothing gets transfered beyond this point. I think this would be mozilla's fault, but I dont think this would happen with a release, and I dont think Mail.app would have the same problem, too.
Thanks for any help,
- Jesse
On Mon, 2003-03-17 at 22:01, Jesse Peterson wrote:
9 UID fetch 4 (UID RFC822.SIZE BODY[]<0.10240>)
- 4 FETCH (UID 4 RFC822.SIZE 3958069 BODY[]<0> {3958069}
It gives too large size for the body data. http://dovecot.procontrol.fi/partial.patch fixes.
I really should create some kind of testing suite which tests as much of the commands/features as possible and shows if any of them fails..
Mail.app still has problems. It gets the first chunk just fine:
9 UID FETCH 25 BODY.PEEK[]<0.8192>
- 25 FETCH (UID 25 BODY[]<0> {8192} <snip> 9 OK Fetch completed.
But then it tries to do the decond chunk:
10 UID FETCH 25 BODY.PEEK[]<8192.6813>
- 25 FETCH (UID 25 BODY[]<8192> {6813}
) 10 OK Fetch completed.
8192 bytes requested and 2(?) returned? Which is weird becuase it worked for other mails that were very large (MB+).
I know Mozilla does a little different method for grabbing chunks then does Mail.app, maybe that has something to do with it.
Thanks,
Timo Sirainen wrote:
On Mon, 2003-03-17 at 22:01, Jesse Peterson wrote:
9 UID fetch 4 (UID RFC822.SIZE BODY[]<0.10240>)
- 4 FETCH (UID 4 RFC822.SIZE 3958069 BODY[]<0> {3958069}
It gives too large size for the body data. http://dovecot.procontrol.fi/partial.patch fixes.
I really should create some kind of testing suite which tests as much of the commands/features as possible and shows if any of them fails..
participants (2)
-
Jesse Peterson
-
Timo Sirainen