> >> I don't think it does be default. The only what I know is to establish > >> a compressed SSH tunnel to your server and then access the server over > >> the tunnel. It will compress and give you an extra layer of encryption. > > > > Umm, no. It will not compress. Think about it, encrypted data is > > fundamentally not compressible, that's the whole point. > > x = length(compress(encrypt(data))) > y = length(encrypt(compress(data))) > z = length(encrypt(data)) > > Then, usually, x > y and z > y, but x is approximately the same as z. > (That's speaking very generally; there may be optimizations in some case > or another given your data.) > > That is: encrypted data is less compressible than the original data, but > if you compress first, then encrypt, it should be a win. > > If I recall correctly, a "compressed SSH tunnel" would do 'y' (compress > then encrypt). i.e., dovecot would see a non-SSL connection which gets > compressed-then-encrypted, or decrypted-then-uncompressed by the endpoints > of the tunnel.
Well, as far as I understood Marc, since he was saying "an extra layer of encryption" I understood him to mean that he wanted to encrypt(compress(encrypt(imap stream))) by building an ssh-tunnelled imaps (or imap/tls) connection. IOW, dovecot would see an SSL connection too. johannes
signature.asc
Description: This is a digitally signed message part
