Hi
It would also appear at first glance that the rawlog doesn't work as I might expect when using COMPRESS ? I see something like this in my logs (but nothing further):
6 compress deflate 2v??uQ??s???Yeah, rawlog logs the data it sees from imap process. The compression is started after logging in, so this happens. You just delete the data before the compress command and then uncompress the rest (although I think gzip doesn't like the input because it doesn't have gz header).
I have fiddled a bit trying to get a valid header
I tried creating one with: echo -n -e "\x1F\x8B"
gunzip then gives me: gzip: test.in.gz: unknown method 50 -- not supported
Examining the raw data makes me suspect that we are missing the header data in the logged output? I'm trying to follow the code in imap_zlib_plugin.c, but I can't see how the logging works?
Can you please help?
- With COMPRESS enabled, 3 accounts work perfectly, but one account hangs at "authenticating" (although the dovecot logs show that it finishes authing and hangs soon after initiating a COMPRESS command) I guess there's a bug somewhere, either in Dovecot or in the client..
I have probed this a bit without being able to see the decompressed output. I have several working accounts using this client, and yet this single account (which also has many more messages than the other accounts) keeps hanging at the "auth" stage. It hasn't changed the symptoms by: adding/removing messages from the account, recreating the settings on the client, fiddling with namespace options - which seems to rule out some of the obvious parsing flaws that could be happening here
I think I need to see inside the data sent to the client. My client has no obvious debugging support, so grateful if you can help construct a valid header here?
Thanks
Ed W