So, just some quick notes:
- dovecot.org server was down a couple of days again, need to find time to move it to a VM..
- my tss@iki.fi emails were also broken for some hours at least and it was bouncing back all mails to it during the time
- I fixed some bugs reported by people, but I did it in airplane so couldn't reply back with links to the fixes in hg repo. I'll probably do that tomorrow. But you can already check if your reported bug has been fixed in http://hg.dovecot.org/dovecot-2.2
- I'm planning on going through Dovecot list's mails this week and make v2.2.11 release
- although it looks like I've a flu, so lets see how far I can get..
- hopefully by the beginning of March I'll have more time again
Il 04/02/2014 23:13, Timo Sirainen ha scritto:
So, just some quick notes:
- dovecot.org server was down a couple of days again, need to find time to move it to a VM..
- my tss@iki.fi emails were also broken for some hours at least and it was bouncing back all mails to it during the time
- I fixed some bugs reported by people, but I did it in airplane so couldn't reply back with links to the fixes in hg repo. I'll probably do that tomorrow. But you can already check if your reported bug has been fixed in http://hg.dovecot.org/dovecot-2.2
- I'm planning on going through Dovecot list's mails this week and make v2.2.11 release
- although it looks like I've a flu, so lets see how far I can get..
- hopefully by the beginning of March I'll have more time again
Hello Timo,
everyone here we hope you'll get better soon, perhaps at FOSDEM you had to put a wool sweater :-)
I have a suggestion/feature request for Dovecot.
Several administrator find useful to have the last login date/IP/protocol for their users, this is useful for help desk.
In Dovecot we can have this features via "Post-login scripting" but it would be nice to have her as a native option.
An idea would be to implement it via dict with Redis or SQL backend (like quota).
Do you think it would be possible? Thanks
Alessio Cecchi is: @ ILS -> http://www.linux.it/~alessice/ on LinkedIn -> http://www.linkedin.com/in/alessice Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz Cloud Email Hosting -> http://www.qboxmail.com @ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it
Hey Timo,
hope you are not fully knocked out by the flu?
On 04.02.2014 23:13, Timo Sirainen wrote:
- I'm planning on going through Dovecot list's mails this week and make v2.2.11 release
Since you sometimes ask for bugs or improvements to take into an upcoming release ... may I nag you again with this idea of self healing the file names / size of zlib compressed maildir files for version >= 2.2.11?
Thread title is: "[Dovecot] Size detection/replair does not work with zlib"
Regards
Christian
On 10.2.2014, at 7.31, Christian Rohmann crohmann@netcologne.de wrote:
Hey Timo,
hope you are not fully knocked out by the flu?
I'm all good now, but traveling once again which makes things more difficult. Although I really should make the v2.2.11 release now even if I haven't read through all the mails.. Maybe the airplane will have wifi, lets see. :)
On 04.02.2014 23:13, Timo Sirainen wrote:
- I'm planning on going through Dovecot list's mails this week and make v2.2.11 release
Since you sometimes ask for bugs or improvements to take into an upcoming release ... may I nag you again with this idea of self healing the file names / size of zlib compressed maildir files for version >= 2.2.11?
That's quite a lot of work for fixing something that shouldn't really be happening in the first place. I think those problems only happen once immediately after enabling zlib plugin and for some reason having the wrong (or missing) S=sizes in maildir filenames? Running http://dovecot.org/tools/maildir-size-fix.pl for all users once should fix that. So I don't really see this worth spending time on.
On Mon, 10 Feb 2014, Timo Sirainen wrote:
may I nag you again with this idea of self healing the file names / size of zlib compressed maildir files for version >= 2.2.11?
That's quite a lot of work for fixing something that shouldn't really be happening in the first place. I think those problems only happen once immediately after enabling zlib plugin and for some reason having the wrong (or missing) S=sizes in maildir filenames?
As far as I can reproduce my problems, this usually happens, if you have a cluster of servers with mail_plugins=zlib enabled, forgot to enable zlib of one of the servers and enable zlib_save.
The zlib enabled servers write compressed mails to disk with correct S-Value.
If you access these compressed mails via the server without zlib plugin, this server will rename the mails to a corrupt S-value, which implies that none of the zlib enabled servers can read the mails any more nor repair them.
Yes, I know, that this a layer 8 problem, but I would sleep better when I'd know that dovecot can repair this issue for me be fixing the S-value automatically.
Running http://dovecot.org/tools/maildir-size-fix.pl for all users once should fix that. So I don't really see this worth spending time on.
This may work on a private site, but not on a big cluster. There a missing zlib plugin will faster break your mailboxes than your script can find the broken boxes...
Tschoeeee
Roland-- Roland Rosenfeld - Teamverantwortlicher Content Delivery - NED - Technik NETCOLOGNE Gesellschaft für Telekommunikation mbH Am Coloneum 9 50829 Köln Tel.: +49 221 2222-373 Fax: +49 221 2222-7373 Geschäftsführer: Jost Hermanns, Mario Wilhelm Vorsitzender des Aufsichtsrates: Dr. Andreas Cerbe HRB 25580, AG Köln
Am 12.02.2014 14:12, schrieb Roland Rosenfeld:
As far as I can reproduce my problems, this usually happens, if you have a cluster of servers with mail_plugins=zlib enabled, forgot to enable zlib of one of the servers and enable zlib_save.
The zlib enabled servers write compressed mails to disk with correct S-Value
If you access these compressed mails via the server without zlib plugin, this server will rename the mails to a corrupt S-value, which implies that none of the zlib enabled servers can read the mails any more nor repair them
the real problem is having such meta-infos in a *filename* that's broken by design
On 12.2.2014, at 22.22, Reindl Harald h.reindl@thelounge.net wrote:
Am 12.02.2014 14:12, schrieb Roland Rosenfeld:
As far as I can reproduce my problems, this usually happens, if you have a cluster of servers with mail_plugins=zlib enabled, forgot to enable zlib of one of the servers and enable zlib_save.
The zlib enabled servers write compressed mails to disk with correct S-Value
If you access these compressed mails via the server without zlib plugin, this server will rename the mails to a corrupt S-value, which implies that none of the zlib enabled servers can read the mails any more nor repair them
the real problem is having such meta-infos in a *filename* that's broken by design
There isn't really any better way to do it with Maildir. This isn't a problem with dbox since the size is in dbox metadata. I guess Dovecot could once again work around it by reading and uncompressing the whole mail when calculating the size, but then instead of getting errors people would just get horrible performance..
Hey Timo,
Roland Rosenfeld rrosenfeld@netcologne.de hat am 12. Februar 2014 um 14:12 geschrieben: On Mon, 10 Feb 2014, Timo Sirainen wrote:
That's quite a lot of work for fixing something that shouldn't really be happening in the first place. I think those problems only happen once immediately after enabling zlib plugin and for some reason having the wrong (or missing) S=sizes in maildir filenames?
Is it really? As far as I understood Rolands original post regarding this issue, all the (meta) data is there. Dovecot does recognize a compressed (Maildir++) file without any tags or meta info in the file name already today. And it more importantly knows the uncompressed size the message has. The only thing that is broken or more accurately put, that could be improved on, is Dovecots ability to use the uncompressed size as S=Value instead of always relying on the file size when setting / fixing the file name.
So in my naive mind this boils down to determining the S-Value the Maildir++ file name is given from the "uncompressed" size variable instead of the size the file has on disk. You could also only branch to this "mode" of a compressed file is recognized. I wildly guess that this is the strategy you need to apply to (m)dbox anyways. To find and index how big each message within a dbox-file really is.
Yes, I know, that this a layer 8 problem, but I would sleep better when I'd know that dovecot can repair this issue for me be fixing the S-value automatically.
As you can probably read between the lines: Once you became to know and simply love the "Dovecot simply fixes problems with a mailbox or its indexes automagically"-paradigm, you miss it on the first case this is not so ...
I might add another use case or nice ability Dovecot has: One can just copy / merge messages on a file by file basis and Dovecot will take care of renaming the files to the Maildir++ format. This does not work anymore if the files are compressed. But provided Dovecot could set the actual size of a compressed file this would again work just fine.
Thanks
Christian
participants (5)
-
Alessio Cecchi
-
Christian Rohmann
-
Reindl Harald
-
Roland Rosenfeld
-
Timo Sirainen