[Dovecot] v2.0.beta3 released
http://dovecot.org/releases/2.0/beta/dovecot-2.0.beta3.tar.gz http://dovecot.org/releases/2.0/beta/dovecot-2.0.beta3.tar.gz.sig
I had to break a few APIs in this release to get some other stuff implemented and fixed. And since I had to break some of them, I decided it could be a good time to do some other less necessary API cleanups. This made things again much simpler.
I'm hoping to get v2.0.rc1 out in not too distant future. Pretty much the only big missing feature that I wanted to do is being able to add per-protocol auth settings (e.g. protocol smtp { userdb { .. } }), but that doesn't seem to be all that easy to implement. There are of course some bugs still left to be fixed, mainly related to mdbox and dsync.
User visible changes:
- imap_zlib plugin implements COMPRESS=DEFLATE IMAP extension
- zlib plugin: Added support for compressing mails while saving
- zlib plugin: fixed reading bzip2 compressed mail files
- zlib plugin: Added support for dbox and mdbox formats
- mdbox: doveadm purge moves old mails to alt storage (if using alt storage)
- added support for tcpwrappers
- added support for SHA512 password scheme (by Mark Washenberger)
- mailbox deletion is now free of race conditions (e.g. quota calculations). if another session tries to access mailbox before it's fully deleted, it'll get "Mailbox is being deleted" error.
- "key = $set" in config file now sets key's value to "set" setting's value. this is probably rather limited outside the only place where I created it for: service { user = $default_internal_user }
- default_internal_user and default_login_user settings now specify what users should be used for them. currently the default is still dovecot and dovecot, but I'm hoping to change default_login_user to something else..
- Removed maildir_copy_preserve_filename setting. It's now always tried to be preserved (or rather: message's GUID is preserved)
- auth failure penalty tries to avoid increasing penalty for IP if auth is failing always with the same user+password combination.
- doveadm penalty command can be used to see the current penalties
- login processes: config lookups are now cached, so it no longer asks for configuration from config process every time (except if there are remote {} blocks in config. also the local {} caching could be smarter.)
- Tons of mdbox fixes
- Tons of dsync fixes, especially with mbox
So some of the changes visible to developers are:
- dovecot-config file changed. if your external plugin uses this file, you need to change it to use the new format.
- added dovecot.m4 file that can be used by external plugins' configure script to get Dovecot settings. This was mainly done by Dennis Schridde.
- mailbox_alloc() no longer has stream parameter, instead there's mailbox_open_stream()
- mailbox_close() renamed to mailbox_free(). added a different mailbox_close(), which only closes opened mailbox, but doesn't free it.
- mailbox_delete(), mailbox_rename() APIs changed
- notify plugin's delete/rename API changed as well
- mailbox GUID is now looked up using mailbox_get_guid(), not mailbox_status()
- dict_iterate*() API changed
Hi,
this is the first 2.0 build I tested, and I haven't been following the 2.0 threads very closely. This said I'm puzzled whether 'protocols = imap' does what it should. It also enables a listener for IMAPS on port 993, different to what 1.2 series did. I had to manually disable the IMAPS part by setting its port to 0.
# 2.0.beta3: /etc/dovecot/dovecot.conf # OS: Linux 2.6.26-2-amd64 x86_64 Debian 5.0.4 info_log_path = /var/log/dovecot-info.log log_path = /var/log/dovecot.log mail_location = maildir:~/maildir namespace { hidden = no inbox = yes location = prefix = separator = / type = private } namespace { list = yes location = maildir:/var/vmail/public:CONTROL=~/maildir/public:INDEX=~/maildir/public prefix = Public/ separator = / subscriptions = no type = public } passdb { args = username_format=%u /var/vmail/conf.d/%d/passwd deny = no driver = passwd-file master = no pass = no } plugin { acl = vfile:/var/vmail/conf.d/%d/acls:cache_secs=300 quota = dict:user::file:%h/maildir/dovecot-quota quota_rule = *:storage=1GB quota_rule2 = Trash:storage=10%% sieve = ~/.dovecot.sieve sieve_dir = ~/sieve sieve_global_dir = /var/vmail/conf.d/%d/sieve-scripts } postmaster_address = postmaster@leuxner.net protocols = imap service auth { unix_listener auth-userdb { group = vmail mode = 0600 user = vmail } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } }
service imap-login { inet_listener imap { address = xxx.xxx.xxx.xxx port = 143 } inet_listener imaps { port = 0 } } ssl_cert =
Regards Thomas
On Sat, 2010-02-20 at 23:41 +0100, Thomas Leuxner wrote:
this is the first 2.0 build I tested, and I haven't been following the 2.0 threads very closely. This said I'm puzzled whether 'protocols = imap' does what it should. It also enables a listener for IMAPS on port 993, different to what 1.2 series did. I had to manually disable the IMAPS part by setting its port to 0.
Yes, that's intentional. imaps isn't a protocol.
On Sun, 2010-02-21 at 07:26 +0100, Thomas Leuxner wrote:
Am 21.02.2010 um 07:16 schrieb Timo Sirainen:
Yes, that's intentional. imaps isn't a protocol.
Thanks Timo. Has the specific logging option for the LDA been dropped? I see it logging to 'info_log_path=' only.
What specific logging option for LDA?.. Seems to work exactly the same as in v1.2:
protocol lda { info_log_path = /tmp/deliver.log }
Am 22.02.2010 um 16:29 schrieb Timo Sirainen:
What specific logging option for LDA?.. Seems to work exactly the same as in v1.2:
protocol lda { info_log_path = /tmp/deliver.log }
Ah ok. Thought all logging ought to be configured in 'logging.conf' as there was no example in 'lda.conf'. Since I switched to lmtp delivery yesterday, would it also be possible to have a different logging path for that?
Thanks Thomas
On 22.2.2010, at 19.49, Thomas Leuxner wrote:
Am 22.02.2010 um 16:29 schrieb Timo Sirainen:
What specific logging option for LDA?.. Seems to work exactly the same as in v1.2:
protocol lda { info_log_path = /tmp/deliver.log }
Ah ok. Thought all logging ought to be configured in 'logging.conf' as there was no example in 'lda.conf'.
No, the config files were split only to hopefully make them easier to manage. You can put any settings anywhere you want.
Since I switched to lmtp delivery yesterday, would it also be possible to have a different logging path for that?
Nope. It would be now much simpler to implement it though. log daemon would just need to support reading/using separate config for each service. Maybe it could even be implemented in less than 50 lines of code..
Am 22.02.2010 um 18:53 schrieb Timo Sirainen:
Since I switched to lmtp delivery yesterday, would it also be possible to have a different logging path for that?
Nope. It would be now much simpler to implement it though. log daemon would just need to support reading/using separate config for each service. Maybe it could even be implemented in less than 50 lines of code..
Maybe an option going forward.
Thanks
On 22.2.2010, at 19.53, Timo Sirainen wrote:
Nope. It would be now much simpler to implement it though. log daemon would just need to support reading/using separate config for each service. Maybe it could even be implemented in less than 50 lines of code..
Oh, actually not. The difficult part is that Dovecot just doesn't support logging to multiple files (with same severity) in a same process. The logging code would have to be abstracted out before that would be possible.
Am 22.02.2010 um 18:59 schrieb Timo Sirainen:
Oh, actually not. The difficult part is that Dovecot just doesn't support logging to multiple files (with same severity) in a same process. The logging code would have to be abstracted out before that would be possible.
Actually I like the idea of having a separate delivery log with lmtp. Any idea?
On 22.2.2010, at 20.19, Thomas Leuxner wrote:
Am 22.02.2010 um 18:59 schrieb Timo Sirainen:
Oh, actually not. The difficult part is that Dovecot just doesn't support logging to multiple files (with same severity) in a same process. The logging code would have to be abstracted out before that would be possible.
Actually I like the idea of having a separate delivery log with lmtp. Any idea?
Some syslog could do that.
participants (2)
-
Thomas Leuxner
-
Timo Sirainen