Prev: How to add more than one recipient on the notice recipient
Next: Postfix DKIM
From: Leonardo Rodrigues on 8 Sep 2009 16:00

Hi,

I was recently playing with dovecot plugins, and one of them caught=20
my attention: zlib. This plugin allows dovecot imap4/pop3 modules to=20
deal with gzipped messages on Maildir+ boxes ... files are stored in=20
compressed format and users can normally check them through IMAP4/POP3,=20
decompression is on-the-fly and users doesnt notice anything.

On several mailboxes i have access and could test, gzipping all=20
message files would save about 40% of storage space. Of course the=20
compression/decompression is a very CPU intensive task ... but 40% of=20
storage saving really calls my attention.

Apparently there's no problem with mailbox quota management because=20
dovecot uses the S=3Dsize parameter which is present on the filenames,=20
which postfix writes correctly, instead of filesize on the file system.

Altough dovecot supports reading gzipped files through IMAP4/POP3=20
modules, it does not automatically compress files on its delivery agent, =

that should be done by some script somehow.

Dovecot delivery agent do not support on-the-fly compression when=20
delivering messages .... but when (and if) dovecot delivery agent=20
supports that on-the-fly compression as well, i'll really study it.

Anyway, as i dont use dovecot delivery agent because postfix virtual =

delivery agent really fits my needs .... i would like to propose a=20
feature request here, the on-the-fly compression on virtual delivery=20
agent, which would be a perfect match for dovecot zlib module i described=
=2E


Because of locking things, that on-the-fly compression/decompression =

is not possible for mbox boxes.


Some minor information about dovecot zlib module:

http://wiki.dovecot.org/Plugins/Zlib

--=20


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, N=C3O mandem email
gertrudes(a)solutti.com.br
My SPAMTRAP, do not email it




From: mouss on 8 Sep 2009 18:16
Leonardo Rodrigues a �crit :
>
> Hi,
>
> I was recently playing with dovecot plugins, and one of them caught
> my attention: zlib. This plugin allows dovecot imap4/pop3 modules to
> deal with gzipped messages on Maildir+ boxes ... files are stored in
> compressed format and users can normally check them through IMAP4/POP3,
> decompression is on-the-fly and users doesnt notice anything.
>
> On several mailboxes i have access and could test, gzipping all
> message files would save about 40% of storage space. Of course the
> compression/decompression is a very CPU intensive task ... but 40% of
> storage saving really calls my attention.
>
> Apparently there's no problem with mailbox quota management because
> dovecot uses the S=size parameter which is present on the filenames,
> which postfix writes correctly, instead of filesize on the file system.
>
> Altough dovecot supports reading gzipped files through IMAP4/POP3
> modules, it does not automatically compress files on its delivery agent,
> that should be done by some script somehow.
>
> Dovecot delivery agent do not support on-the-fly compression when
> delivering messages .... but when (and if) dovecot delivery agent
> supports that on-the-fly compression as well, i'll really study it.
>
> Anyway, as i dont use dovecot delivery agent because postfix virtual
> delivery agent really fits my needs .... i would like to propose a
> feature request here, the on-the-fly compression on virtual delivery
> agent, which would be a perfect match for dovecot zlib module i described.
>
>
> Because of locking things, that on-the-fly compression/decompression
> is not possible for mbox boxes.
>
>
> Some minor information about dovecot zlib module:
>
> http://wiki.dovecot.org/Plugins/Zlib
>

I don't wanna sound negative, but
- since dovecot solves the problem...
- this can also be handled at fielsystem level
- every time I hear "zlib", someting like "vulnerability" hits my ears.
so if I can vote, I'd say no to zlib integration. this applies to
dovecot too. unfortunately, it seems that Timo is "too open", which
makes the "with security in mind" of dovecot debatable at least. is it
time to move back to courier?
- the best code is that you don't write
....



From: Noel Jones on 8 Sep 2009 21:08
On 9/8/2009 2:59 PM, Leonardo Rodrigues wrote:
>
> Hi,
>
> I was recently playing with dovecot plugins, and one of them caught my
> attention: zlib. This plugin allows dovecot imap4/pop3 modules to deal
> with gzipped messages on Maildir+ boxes ... files are stored in
> compressed format and users can normally check them through IMAP4/POP3,
> decompression is on-the-fly and users doesnt notice anything.
....
> Anyway, as i dont use dovecot delivery agent because postfix virtual
> delivery agent really fits my needs .... i would like to propose a
> feature request here, the on-the-fly compression on virtual delivery
> agent, which would be a perfect match for dovecot zlib module i described.

The postfix virtual delivery agent is intentionally
bare-bones. Any new feature discussed would need to be
compelling and widely usable; compressed maildir support is
neither.

The right place for this feature is the dovecot deliver
program, not postfix virtual.

-- Noel Jones
From: Seth Mattinen on 8 Sep 2009 23:49
mouss wrote:
> Leonardo Rodrigues a �crit :
>>
>> http://wiki.dovecot.org/Plugins/Zlib
>>
>
> I don't wanna sound negative, but
> - since dovecot solves the problem...
> - this can also be handled at fielsystem level
> - every time I hear "zlib", someting like "vulnerability" hits my ears.
> so if I can vote, I'd say no to zlib integration. this applies to
> dovecot too. unfortunately, it seems that Timo is "too open", which
> makes the "with security in mind" of dovecot debatable at least. is it
> time to move back to courier?

Well, it *is* a plugin, just don't enable it and you're zlib free. I'll
agree with you on the "too open" part though.

~Seth
From: Timo Sirainen on 9 Sep 2009 01:06
On Sep 8, 2009, at 6:16 PM, mouss wrote:

> - every time I hear "zlib", someting like "vulnerability" hits my
> ears.

Well, you inspired me to finally implement a prevention method against
almost all vulnerabilities there could be in zlib: http://hg.dovecot.org/dovecot-1.2/rev/b359aac78f92
I had been planning this since the beginning, but since few people
used zlib plugin I guess I always just treated it as second class
citizen and thought other things were more important. And sure, that
patch doesn't help if users have some other way of writing files to
maildir, but in typical setups I would now consider using zlib plugin
safe.

> so if I can vote, I'd say no to zlib integration. this applies to
> dovecot too. unfortunately, it seems that Timo is "too open", which
> makes the "with security in mind" of dovecot debatable at least. is it
> time to move back to courier?

I try to keep the defaults secure, but I also understand that others
just want the best performance and fancy features.

 | 
Pages: 1
Prev: How to add more than one recipient on the notice recipient
Next: Postfix DKIM