[Dovecot] Feature request - statistics for the COMPRESS imap protocol

[Ed W]

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