Re: Replication going away?
On Sun, Jul 09, 2023 at 10:36:35PM +0300, Vladimir Mishonov via dovecot wrote: > Looking at the commit details, it appears that it completely removes the > replication feature. I am not very upset with that news, since all I have been able to do with replicator was loosing mail. However, I understand some had a better experience with it. I am curious if someone will fork dovecot and restore the beloved feature. -- Emmanuel Dreyfus m...@netbsd.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Outlook vs Thunderbird
On Thu, Jul 16, 2020 at 12:16:19PM +1000, Mark Constable wrote: > Would anyone with Windows7 clients be able to provide me with the > EXACT set of ssl_* settings that should work with W7 please? Also consider improving Windows 7 TLS usage: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi -- Emmanuel Dreyfus m...@netbsd.org
Re: Dovecot HA/Resilience
On Fri, Jan 10, 2020 at 09:07:24AM +0200, Aki Tuomi wrote: > Replication is not supported with mbox. Most features are not. It would be nice if the document about replication could tell what setup works. -- Emmanuel Dreyfus m...@netbsd.org
Re: Dovecot HA/Resilience
On Thu, Jan 09, 2020 at 06:51:36PM +0200, Aki Tuomi wrote: > You can do it using replication, > https://wiki.dovecot.org/Replication Last time I tried, it did not work with mbox. Did that change? The document does not tell about the format. -- Emmanuel Dreyfus m...@netbsd.org
Re: dsync panic in mbox_lock
Aki Tuomi <aki.tu...@dovecot.fi> wrote: > We have seen this before but so far the actual bug has not been > reproducible for us. Can you post your doveconf -n Here it is: https://ftp.espci.fr/shadow/manu/conf.log > and also logs with > doveadm -Dv -o plugin/mail_replica=remoteprefix:r...@mail2.example.net > sync -d -u jdoe https://ftp.espci.fr/shadow/manu/sync.log -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
dsync panic in mbox_lock
Hello I am trying to setup replication with dovecot-2.2.29.1, and for some users, I get a reproductible panic: # doveadm -v -o plugin/mail_replica=remoteprefix:r...@mail2.example.net sync -d -u jdoe dsync-local(jdoe): Panic: file mbox-lock.c: line 799 (mbox_lock): assertion failed: (lock_type == F_RDLCK || mbox->mbox_lock_type != F_RDLCK) Abort User is not overquota, and filesystem permissions are correct. kernel trace shows it happens just after a stat() on INBOX/dovecot.ind ex.log. Here is doveadm backtrace: #0 0x7f7ff650e6fa in _lwp_kill () from /lib/libc.so.12 #1 0x7f7ff650e385 in abort () from /lib/libc.so.12 #2 0x7f7ff6c91acc in default_fatal_finish () from /usr/pkg/lib/dovecot/libdovecot.so.0 #3 0x7f7ff6c91b4a in default_fatal_handler () from /usr/pkg/lib/dovecot/libdovecot.so.0 #4 0x7f7ff6cbcb9b in i_panic () from /usr/pkg/lib/dovecot/libdovecot.so.0 #5 0x7f7ff7076721 in mbox_lock () from /usr/pkg/lib/dovecot/libdovecot-storage.so.0 #6 0x7f7ff7077da7 in mbox_save_begin () from /usr/pkg/lib/dovecot/libdovecot-storage.so.0 #7 0x7f7ff580c3f8 in quota_save_begin () from /usr/pkg/lib/dovecot/lib10_quota_plugin.so #8 0x7f7ff7047f63 in mailbox_save_begin () from /usr/pkg/lib/dovecot/libdovecot-storage.so.0 #9 0x7f7ff703d983 in mail_storage_copy () from /usr/pkg/lib/dovecot/libdovecot-storage.so.0 #10 0x7f7ff5401f10 in notify_copy () from /usr/pkg/lib/dovecot/lib15_notify_plugin.so #11 0x7f7ff580c259 in quota_copy () from /usr/pkg/lib/dovecot/lib10_quota_plugin.so #12 0x7f7ff70480f8 in mailbox_copy_int () from /usr/pkg/lib/dovecot/libdovecot-storage.so.0 #13 0x7f7ff70482a5 in mailbox_move () from /usr/pkg/lib/dovecot/libdovecot-storage.so.0 #14 0x0043a118 in ?? () #15 0x0043b465 in ?? () #16 0x0043db03 in dsync_mailbox_import_changes_finish () #17 0x0043906c in dsync_brain_sync_mails () #18 0x00434e4d in dsync_brain_run () #19 0x0043514b in ?? () #20 0x00447ca9 in ?? () #21 0x7f7ff6ca3e65 in io_loop_call_io () from /usr/pkg/lib/dovecot/libdovecot.so.0 #22 0x7f7ff6ca5179 in io_loop_handler_run_internal () from /usr/pkg/lib/dovecot/libdovecot.so.0 #23 0x7f7ff6ca3efa in io_loop_handler_run () from /usr/pkg/lib/dovecot/libdovecot.so.0 #24 0x7f7ff6ca4099 in io_loop_run () from /usr/pkg/lib/dovecot/libdovecot.so.0 #25 0x004205b2 in ?? () #26 0x00422754 in ?? () #27 0x00423074 in ?? () #28 0x004238d1 in doveadm_mail_try_run () #29 0x0045182a in main () Any hint? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
mail_log_events and dsync
Hello mail_log_events is handy to track what happened to a given message. Unfortunatly, it seems dsync activity is not captured. This causes messages to appear or vanish without a log trace. Did I miss a setting to get it? How should I track how something went wrong with dsync? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Correct settings for ssl protocols" and "ssl ciphers"
On Tue, Jan 17, 2017 at 07:55:15AM -0500, Jerry wrote: > I have seen different configurations while Googling. I am wondering > what the consensus is for the best settings for these two items. What > do the developers recommend? According to my own reference https://arxiv.org/abs/1407.2168 I use: ssl_dh_parameters_length = 4096 ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL You may want to disable 3DES nowadays. -- Emmanuel Dreyfus m...@netbsd.org
Checking index sanity
Hello We experienced corrupted dovecot indexes, probably caused by a server crash. This does not cause a lot of harm, just annoyance. For instance, LMTP raises an assertion during delivery, which causes mail to multiple recipients e-mail to remain in the queue if a single of them hits a corrupted index. The workaround for now is to detect the situation in the logs and to remove corrupted indexes when the problem arise. A better fix would be to sanity check all user's index on startup. Is there a command line tool to do this? -- Emmanuel Dreyfus m...@netbsd.org
Re: FREAK/Logjam, and SSL protocols to use
On Tue, May 26, 2015 at 03:37:39PM +0100, Ron Leach wrote: What SSL protocols do folk on the list recommend should be allowed in Dovecot these days? (Actually, I mean which protocols really 'must' be disallowed?) I use this: ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL ssl_dh_parameters_length = 4096 Kissing SSLv3 good bye did not cause harm to clients. Next to be phased out is 3DES which accounts for 0.25% o the connexions according to the logs. I suspect the offending clients could do better. -- Emmanuel Dreyfus m...@netbsd.org
Re: New FREAK SSL Attack CVE-2015-0204
On Wed, Mar 04, 2015 at 06:13:31PM +0200, Adrian Minta wrote: Hello, about the CVE-2015-0204, in apache the following config seems to disable this vulnerability: SSLProtocol All -SSLv2 -SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4 Is something similar possible with dovecot ? I use this with some succes: # dovecot has built-in protection against BEAST, therefore no need # to remove -SSLv2-SHA1:-TLSv10-SHA1 ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL I only had a single report of an old client being locked out. Oddly it was a recent Windows Phone that was perfectly capable of using latest protocol and ciphers. While there, I will self advertise my own paper on TLS hardening: http://arxiv.org/abs/1407.2168 -- Emmanuel Dreyfus m...@netbsd.org
Re: New FREAK SSL Attack CVE-2015-0204
On Wed, Mar 04, 2015 at 06:36:07PM +0200, Adrian Minta wrote: Thank you for the answer. The !EXPORT part is included in ECDH@STRENGTH:DH@STRENGTH:HIGH, or it must be added as well ? This is not the cipher list I sent. It was: ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNUL Mine does not contain any export cipher, yours does. You can use openssl ciphers to compare cipher lists: $ openssl ciphers EXPORT|tr ':' '\n' |sort export $ openssl ciphers ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL \ |tr ':' '\n' |sort manu $ openssl ciphers ECDH@STRENGTH:DH@STRENGTH:HIGH |tr ':' '\n' |sort adrian $ join export manu (nothing) $ join export adrian EXP-ADH-DES-CBC-SHA EXP-ADH-RC4-MD5 EXP-EDH-DSS-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA -- Emmanuel Dreyfus m...@netbsd.org
Re: Does dovecot work OK on *BSD?
On Fri, Sep 26, 2014 at 03:03:13PM +1200, Mark Davies wrote: dovecot 2.2.13 works very nicely here via pkgsrc on NetBSD. Same here, works fine on NetBSD. -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] BUG: Authentication client sent unknown handshake command
Emmanuel Dreyfus m...@netbsd.org wrote: I checked with a test program: on a non open, or closed socket, getsockname() returns -1. However on a socket that was not bound, it returns 0 and fills the buffer with garbage. Wrong diagnostic. I am now tracking synchronisation problems between auth and imap-login. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] BUG: Authentication client sent unknown handshake command
Emmanuel Dreyfus m...@netbsd.org wrote: Nov 29 16:56:01 volanges dovecot: auth: Error: BUG: Authentication client sent unknown handshake command: REQUEST?6970356762?616?6?235264ef69dbd1665538af54... I have real trouble to debug that one. I had a look at wiki2.dovecot.org/Design/AuthProtocol, and if I understand correctly, the auth server receives data from the master where it awaits data from the auth client. That suggests some confusion with file descriptors somewhere. Where are the pipe() invocation to create these two pipe sets? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] BUG: Authentication client sent unknown handshake command
Timo Sirainen t...@iki.fi wrote: I think net_getunixname() no longer works correctly. src/auth/main.c uses it to figure out what each socket is. Indeed, when the auth process calls net_getunixname(), getsockname() fills the name buffer with garbage. That happens with fd 7 for instance, and inspecting the process with fstat(1) I see no fd 7. I am not yet sure if it is closed before or after getsockname() # ps -axp 6025 6025 ? I0:00.02 dovecot/auth -w # fstat -p 6025 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root auth6025 wd / 636320 drwxr-xr-x1024 r root auth60250 / 68173 crw-rw-rw-null w root auth60251 / 68173 crw-rw-rw-null w root auth60252* pipe 0xc732d254 - 0xc710c010 w root auth60253* pipe 0xc725e310 - 0xc70b330c w root auth60254 / 545650 -rw-r--r-- 121 r root auth60255* pipe 0xc725ecd0 - 0xc710c0d0 wn root auth60256* pipe 0xc7be385c - 0xc79b885c w root auth60255* misc 0xc67dff18 root auth60259* pipe 0xc7057f04 - 0xc618f000 rn root auth6025 10* pipe 0xc618f000 - 0xc7057f04 wn root auth60254* kqueue pending 0 root auth60254* kqueue pending 0 root auth6025 13 / 545650 -rw-r--r-- 121 r root auth6025 14* internet stream tcp 192.0.2.16:636 - 192.0.2.26:62473 root auth6025 15* unix stream - /var/run/dovecot/auth-worker root auth6025 130 / 545650 -rw-r--r-- 121 r The other auth process has it as a Unix socket like we expect: # ps -axp 17204 PID TTY STATTIME COMMAND 17204 ? I0:00.02 dovecot/auth # fstat -p 17204 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root auth 17204 wd / 636320 drwxr-xr-x1024 r root auth 172040 / 68173 crw-rw-rw-null w root auth 172041 / 68173 crw-rw-rw-null w root auth 172042* pipe 0xc725e250 - 0xc618ee40 w root auth 172043* pipe 0xc725e310 - 0xc70b330c w root auth 172044 / 545650 -rw-r--r-- 121 r root auth 172045* pipe 0xc7058184 - 0xc710c9d0 wn root auth 172046* pipe 0xc7be385c - 0xc79b885c w root auth 172047* unix stream - /var/run/dovecot/login/login root auth 172048* unix stream - /var/run/dovecot/token-login/tokenlogin root auth 172049* unix stream - /var/run/dovecot/auth-login root auth 17204 10* unix stream - /var/run/dovecot/auth-client root auth 17204 11* unix stream - /var/run/dovecot/auth-userdb root auth 17204 12* unix stream - /var/run/dovecot/auth-master root auth 172045* misc 0xc67dff60 root auth 17204 14* unix stream - c71b6e14 root auth 172044* kqueue pending 0 root auth 17204 16* pipe 0xc70b36cc - 0xc7058244 rn root auth 17204 17* pipe 0xc7058244 - 0xc70b36cc wn root auth 172044* kqueue pending 0 root auth 17204 19 / 545650 -rw-r--r-- 121 r root auth 17204 20* internet stream tcp 192.0.2.15:636 - 192.0.2.26:62459 root auth 17204 22* unix stream - c60cb974 root auth 17204 130 / 545650 -rw-r--r-- 121 r -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] BUG: Authentication client sent unknown handshake command
Emmanuel Dreyfus m...@netbsd.org wrote: Indeed, when the auth process calls net_getunixname(), getsockname() fills the name buffer with garbage. I checked with a test program: on a non open, or closed socket, getsockname() returns -1. However on a socket that was not bound, it returns 0 and fills the buffer with garbage. I suspect this is a kernel bug, but how do we reach that situation? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
[Dovecot] BUG: Authentication client sent unknown handshake command
Hi After upgrading the kernel, everything is fine, except dovecot authentication. I get this trange thing (data after REQUEST? changed just in case it contains anything sensitive): Nov 29 16:56:01 volanges dovecot: auth: Error: BUG: Authentication client sent unknown handshake command: REQUEST?6970356762?616?6?235264ef69dbd1665538af54d12fdaea?session_pid=453?req... Nov 29 16:56:01 volanges dovecot: imap: Error: Authentication server didn't send valid SPID as expected: MECH PLAIN plaintext Nov 29 16:56:01 volanges dovecot: imap: Error: Disconnected from auth server, aborting (client-pid=161 client-id=1) Nov 29 16:56:01 volanges dovecot: imap-login: Internal login failure (pid=161 id=1) (internal failure, 1 successful auths): user=jdoe, method=PLAIN, rip=192.0.2.251, lip=192.0.2.10, mpid=453, TLS, TLSv1 with cipher AES128-SHA (128/128 bits) Reverting to the previous kernel fixed the problem, but I have not been able to spot what the problem was. Any idea? -- Emmanuel Dreyfus m...@netbsd.org
[Dovecot] dovecot and PFS
Hi Is there known advices on how to favor PFS with dovecot? In Apache, I use the following directives, with cause all modern browsers to adopt 256 bit PFS ciphers, while keeping backward compatibility with older browsers and avoiding BEAST attack: SSLProtocol all -SSLv2 SSLHonorCipherOrder On SSLCipherSuite ECDHE@STRENGTH:ECDH@STRENGTH:DH@STRENGTH:HIGH:-SSLv3-SHA1:-TLSv10 -SHA1:RC4:!MD5:!DES:!aNULL:!eNULL dovecot does not care about BEAST, since attacker cannot inject trafic. Therefore the cipher list get simplier in dovecot.conf: ssl_cipher_list = ECDHE@STRENGTH:ECDH@STRENGTH:DH@STRENGTH:HIGH:!MD5:!DES:!aNULL :!eNULL But that list is good for browsers. I am not aware of documentation about what ciphers are advertised by various mail client. How can I know if that setting has some success pushing PFS? How can I discover which clients fail to negociate PFS ciphers? -- Emmanuel Dreyfus m...@netbsd.org
[Dovecot] partionning users among backends
Hi I face growing load on a mailserver, and I would like to spread the load on multiple machines. I made a first attempt with dsync but got burnt with issues with mbox, therefore now I am looking for another safer approach. Partitionning users on multiple backends would address my load problem. I would have 50% of users on mail1.example.net and 50% on mail2.example.net, but I need to correctly redirect users requests, as their mail user agents only know about mail.example.net. Is dovecot able to send request to the local machine or to proxy them to another one, depending on information it would have on user mailboxes location? If it does, do we have documentation on this? -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] dovecot 2.2.0 corrupts mailboxes?
On Thu, May 16, 2013 at 06:37:45AM -0400, Charles Marcus wrote: I never looked at it, but I assume they both use flock or fcntl Can't help with your actual problem, but... What was it that 'assumption' is supposedly the mother of? I don't buy that explanation: everything worked fine for years. -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] dovecot 2.2.0 corrupts mailboxes?
On Wed, May 15, 2013 at 02:50:55PM +0300, Timo Sirainen wrote:
There are some locking code changes between v2.1 and v2.2, which
I guess might be buggy. But I can't reproduce any corruption with
stress testing. What's your doveconf -n output? Are you delivering
mails via dovecot-lda or something external?
dovecot -n is below. dovecot takes care of delivery, through LMTP.
Additionnal thoughts on possible problems:
- one of the users was using mutt locally and accessed its mailbox directly
without going through dovecot.
- I experimented dsync replication from another machine that was not
accessible through POP/IMAP/SMTP, perhaps this is what caused chaos?
auth_mechanisms = plain login
disable_plaintext_auth = no
first_valid_uid = 400
mail_location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=/mail/indexes/%u:SUBSCRIPTI
ONS=../.mailboxlist
mbox_very_dirty_syncs = yes
passdb {
args = max_requests=1 cache_key=%u dovecot
driver = pam
}
passdb {
args = /etc/dovecot-ldap.conf
driver = ldap
}
plugin {
autosubscribe = INBOX
quota = fs:User quota
quota_warning = storage=95%% quota-warning %u
}
quota_full_tempfail = yes
service anvil {
client_limit = 1639
}
service auth {
client_limit = 1736
user = root
}
service imap-login {
chroot = login
process_limit = 1024
}
service imap {
process_limit = 680
}
service lmtp {
process_min_avail = 5
unix_listener lmtp {
group = smmsp
mode = 0660
}
}
service pop3-login {
chroot = login
process_limit = 512
}
service pop3 {
process_limit = 680
}
service quota-warning {
executable = script /usr/local/sbin/morts
unix_listener quota-warning {
mode = 0666
}
user = root
}
ssl_ca = /etc/openssl/certs/caespci2006.crt
ssl_cert = /etc/openssl/certs/volanges2012tcs-bundle.crt
ssl_key = /etc/openssl/private/volanges2012.key
userdb {
driver = passwd
}
userdb {
args = /etc/dovecot-ldap.conf
driver = ldap
}
protocol imap {
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
mail_max_userip_connections = 8
mail_plugin_dir = /usr/pkg/lib/dovecot
mail_plugins = quota imap_quota
}
protocol pop3 {
mail_max_userip_connections = 2
mail_plugin_dir = /usr/pkg/lib/dovecot
mail_plugins = quota
mbox_dirty_syncs = yes
pop3_no_flag_updates = no
pop3_uidl_format = %08Xu%08Xv
}
protocol lmtp {
mail_plugins = quota
postmaster_address = postmas...@example.net
}
--
Emmanuel Dreyfus
m...@netbsd.org
Re: [Dovecot] dovecot 2.2.0 corrupts mailboxes?
On Wed, May 15, 2013 at 09:36:54PM +0300, Timo Sirainen wrote:
- one of the users was using mutt locally and accessed its mailbox directly
without going through dovecot.
That shouldn't cause problems if locking was configured the same.
I never looked at it, but I assume they both use flock or fcntl since
this is local storage. And it worked fine for a while, therefore there
is no hint it could be wrong.
- I experimented dsync replication from another machine that was not
accessible through POP/IMAP/SMTP, perhaps this is what caused chaos?
That might cause trouble. I tested today and dsync was doing some strange
things with mbox.
What is the advised setup? Here is the additionnal config I tried on
the inacessible host:
mail_plugins = $mail_plugins notify replication
service replicator {
process_min_avail = 1
}
dsync_remote_cmd = ssh -lroot %{host} doveadm dsync-server -u%u
plugin {
mail_replica = remote:r...@server1.example.net
}
service aggregator {
fifo_listener replication-notify-fifo {
user = dovecot
}
unix_listener replication-notify {
user = dovecot
}
}
service replicator {
unix_listener replicator-doveadm {
mode = 0600
}
}
service replicator {
unix_listener replicator-doveadm {
mode = 0600
}
}
service doveadm {
inet_listener {
port = 12345
ssl = yes
}
}
doveadm_port = 12345
ssl_client_ca_file = /etc/openssl/certs/tcs-chain.crt
doveadm_proxy_port = 0
--
Emmanuel Dreyfus
m...@netbsd.org
Re: [Dovecot] dovecot 2.2.0 corrupts mailboxes?
On Mon, May 06, 2013 at 01:52:55PM -0400, Oscar del Rio wrote: Have you tried 2.2.1? Will do, but since the problem cannot be reliabily reproduced, I have no way of knowing it is fixed. Is there anything in 2.2.1 changelog that hints it could be fixed? -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] dovecot 2.2.0 corrupts mailboxes?
On Mon, May 06, 2013 at 04:20:52PM +0200, Morten Stevens wrote: May 4 21:15:17 volanges dovecot: imap(jdoe): Error: Corrupted index cache file /mail/indexes/jdoe/mail/.imap/Commandes/dovecot.index.cache: Broken physical size for mail UID 680 Does that ring a bell? I am tempted to downgrade to 2.1.13. Does it makes sense? Is it safe to do so? This bug has been fixed with dovecot 2.1.14. But I am running 2.2.0 ... -- Emmanuel Dreyfus m...@netbsd.org
[Dovecot] dovecot 2.2.0 corrupts mailboxes?
Hi On april 17th, I upgraded from dovecot 2.1.13 to 2.2.0. Since that time, I had two different users that reported received three incident of messages that disapeared from their mailboxes. The mailbox format is mbox on local FFS filesystem (no NFS), and I use filesystem quotas (but both users are far from filling their quotas). When the message disapeared, it was always a whole rand of dates. On the last incident reported, the user also saw some message being duplicated many times. There is something interesting in the logs: May 4 20:16:30 volanges dovecot: imap(jdoe): Error: Cached message size smaller than expected (2000 8063) May 4 20:16:30 volanges dovecot: imap(jdoe): Error: Corrupted index cache file /mail/indexes/jdoe/.imap/INBOX/dovecot.index.cache: Broken physical size for mail UID 141869 May 4 20:19:48 volanges dovecot: imap(jdoe): Error: Cached message size smaller than expected (9711 16248) May 4 20:19:48 volanges dovecot: imap(jdoe): Error: Corrupted index cache file /mail/indexes/jdoe/mail/.imap/Arxiv/dovecot.index.cache: Broken physical size for mail UID 4383 May 4 21:14:35 volanges dovecot: imap(jdoe): Error: Cached message size smaller than expected (1878 8066) May 4 21:14:35 volanges dovecot: imap(jdoe): Error: Corrupted index cache file /mail/indexes/jdoe/mail/.imap/CNRS/dovecot.index.cache: Broken physical size for mail UID 290 May 4 21:15:17 volanges dovecot: imap(jdoe): Error: Cached message size smaller than expected (17285 24440) May 4 21:15:17 volanges dovecot: imap(jdoe): Error: Corrupted index cache file /mail/indexes/jdoe/mail/.imap/Commandes/dovecot.index.cache: Broken physical size for mail UID 680 Does that ring a bell? I am tempted to downgrade to 2.1.13. Does it makes sense? Is it safe to do so? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
[Dovecot] quota-related crash for doveadm dsync operation
Hi
I understand the crash below is caused by filesystem quota. I just report
it because perhaps it could have a more graceful failure.
Apr 29 09:39:17 danceny dovecot: dsync-local(jdoe): Error: Mailbox Sent: Saving
failed: Not enough disk space
Apr 29 09:39:17 danceny syslogd[165]: last message repeated 4 times
Apr 29 09:39:17 danceny dovecot: doveadm: Error: dsync-remote(jdoe): Error:
Cached message size smaller than expected (35111 40830)
Apr 29 09:39:17 danceny dovecot: doveadm: Error: dsync-remote(jdoe): Error:
Corrupted index cache file /mail/indexes/jdoe/.imap/Sent/dovecot.index.cache:
Broken physical size for mail UID 976
Apr 29 09:39:17 danceny dovecot: doveadm: Error: dsync-remote(jdoe): Error:
dsync(local): read(/home/pct/jdoe/mail/Sent) failed: Invalid argument
Apr 29 09:39:17 danceny dovecot: dsync-local(jdoe): Error:
dsync(r...@volanges.net.espci.fr): read() failed: Broken pipe
Apr 29 09:39:17 danceny dovecot: dsync-local(jdoe): Panic: file mail-storage.c:
line 1830 (mailbox_transaction_commit_get_changes): assertion failed: (ret 0
|| seq_range_count(changes_r-saved_uids) == save_count ||
array_count(changes_r-saved_uids) == 0)
Apr 29 09:39:17 danceny dovecot: dsync-local(jdoe): Fatal: master:
service(doveadm): child 23443 killed with signal 6 (core not dumped - set
service doveadm { drop_priv_before_exec=yes })
--
Emmanuel Dreyfus
m...@netbsd.org
[Dovecot] many SSH connexions with dsynx/SSH replication
Hi
I am trying replication over dsync/ssh, as explained there:
http://wiki2.dovecot.org/Replication
I added the options below to dovecot.conf. It works, but it
seems there is a new SSH connexion for each user, which is a bit
overkill performance-wise. Since I sync as root, I guess there
is a way of haing everything on the same SSH connexion?
--- cut here ---
mail_plugins = $mail_plugins notify replication
service replicator {
process_min_avail = 1
}
dsync_remote_cmd = ssh -lroot %{host} doveadm dsync-server -u%u
plugin {
mail_replica = remote:r...@mail1.example.net
}
service aggregator {
fifo_listener replication-notify-fifo {
user = dovecot
}
unix_listener replication-notify {
user = dovecot
}
}
service replicator {
unix_listener replicator-doveadm {
mode = 0600
}
}
service doveadm {
inet_listener {
port = 12345
ssl = yes
}
}
doveadm_port = 12345
ssl_client_ca_file = /etc/openssl/certs/ca.crt
doveadm_proxy_port = 0
--- cut here ---
--
Emmanuel Dreyfus
m...@netbsd.org
[Dovecot] dovecot-2.2 Warning: autocreate plugin is deprecated, use mailbox { auto } setting instead
Hi
After upgrading to 2.2, I get this:
Warning: autocreate plugin is deprecated, use mailbox { auto } setting
instead
I found no documentation on mailbox { auto }. Where should it go in the
config file?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
Re: [Dovecot] dovecot-2.2 Warning: autocreate plugin is deprecated, use mailbox { auto } setting instead
Oli Schacher dove...@lists.wgwh.ch wrote:
http://wiki2.dovecot.org/MailboxSettings
I am not sure on how to make it fit at mine. doveconf -n says this:
mail_location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=/mail/indexes/%u:
SUBSCRIPTIONS=../.mailboxlist
(...)
plugin {
autocreate = INBOX
autosubscribe = INBOX
quota = fs:User quota
quota_warning = storage=95%% quota-warning %u
}
What should I have instead? Something like this?
mail_location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=/mail/indexes/%u:
SUBSCRIPTIONS=../.mailboxlist
(...)
plugin {
autosubscribe = INBOX
quota = fs:User quota
quota_warning = storage=95%% quota-warning %u
}
namespace inbox {
mailbox INBOX {
auto = create
}
}
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
[Dovecot] [PATCHES] NetBSD support, authentication buffer size
Hi Here are a few unintegrated patches, just tested against 2.2rc7: 1) NetBSD's getmntinfo uses struct statvfs while other BSD use struct statfs http://ftp.espci.fr/shadow/manu/patch-ak 2) NetBSD 5.x net_getunixcred() support. Build on NetBSD, but not tested (I am testing on NetBSD 6.0): http://ftp.espci.fr/shadow/manu/patch-src_lib_net.c 3) Increase authentication buffer size so that it can cope with unusual authentication scheme. This patch was integrated in dovecot-1.x but did not make its way in dovecot-2.x http://ftp.espci.fr/shadow/manu/patch-src_lib-master_master-auth.h -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] [PATCHES] NetBSD support, authentication buffer size
Timo Sirainen t...@iki.fi wrote: By this I think you don't mean special authentication mechanisms, or even AUTHENTICATE PLAIN mechanism, but you mean that someone is using LOGIN command in such a kludgy way that the password field is over 1024 bytes long? This is for pam_saml. The webmail sends a signed SAML assertion as the password, and the PAM module validates it. You did support in in 1.x and it did not harm anyone... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] [PATCHES] NetBSD support, authentication buffer size
On Thu, Apr 11, 2013 at 02:54:01PM +0300, Timo Sirainen wrote: This is for pam_saml. The webmail sends a signed SAML assertion as the password, and the PAM module validates it. The pam_saml could easily be changed to use AUTHENTICATE PLAIN instead. pam_saml is not the component that choose the authentication. The webmail does. Squirrelmail does not support PLAIN. You did support in in 1.x and it did not harm anyone? It does make it easier to waste the (pre-login!) process memory usage. Perhaps it could be configurable? -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] [PATCHES] NetBSD support, authentication buffer size
On Thu, Apr 11, 2013 at 12:57:45PM +, Emmanuel Dreyfus wrote: Perhaps [MASTER_AUTH_MAX_DATA_SIZE] could be configurable? I tried to add a configuration option for that, but dovecot design makes a good job at separating master and login structures, hence The Right Way is not obvious. Anu suggestion? -- Emmanuel Dreyfus m...@netbsd.org
[Dovecot] environment for dovecot auth
Hi Is there a way to set environment variables for the auth process? All I found for now is to replace it by a shell script that sets variables and then launch the real auth, but I wonder if there is a better way. -- Emmanuel Dreyfus m...@netbsd.org
[Dovecot] [PATCH] support for NetBSD 6.0 libquota
Hi NetBSD 6.0 introduced a new improved quota subsystem and an unified API (libquota) to handle the new and old quota implementation. dovecot is unable to use the new quota implementation right now, and will even fail to build with the old quota API on NetBSD 6.0: Here are dovecot patches to support NetBSD libquota: http://ftp.espci.fr/shadow/manu/dovecot-libquota.tgz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
[Dovecot] dsync
Hi Testing dsync, things go wrong: doveadm sync -u user remote:r...@mail2.example.net dsync-local(user): Error: Mailboxes don't have unique GUIDs: 72e3be2c6f203b50883c44af56a8 is shared by RT and RT_72e3be2c6f203b50883c44af56a8 Obviously RT_72e3be2c6f203b50883c44af56a8 is an outdated copy of RT But .mailboxlist does not list that mailbox. Is there a trick to make sure dsync only use valid mailboxes? I have this in dovecot.conf mail_location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=/mail/indexes/%u:SUBSCRIPTI ONS=../.mailboxlist Another problem, that may or may not be related: dsync-local(user): Error: Next message unexpectedly corrupted in mbox file /home/user/mail/RT at 60298748 dsync-local(user): Error: Failed to sync mailbox RT: Timeout while waiting for lock dsync-local(user): Error: Next message unexpectedly corrupted in mbox file /home/user/mail/RT at 63587421 dsync-local(user): Error: Failed to sync mailbox RT: Mailbox GUIDs are not permanent without index files I also get this: dsync-local(user): Error: Failed to sync mailbox RT: Mailbox GUIDs are not permanent without index files dsync-local(user): Error: proxy client timed out (waiting for MSG-GET message from remote) And this: dsync-local(user): Error: read() from worker server failed: EOF And generally speaking ,how good is dsync? is it usabel in production? This is on dovecot 2.1.7 -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] Auth worker max line size
Timo Sirainen t...@iki.fi wrote: Couldn't you change the client to use AUTHENTICATE PLAIN command instead? The buffer wouldn't be a problem then.. Sorry for the delay, I missed the reply. That is not an option, as the client is not SASL capable. --- src/lib-master/master-auth.h.orig +++ src/lib-master/master-auth.h @@ -13,9 +13,9 @@ /* Authentication client process's cookie size */ #define MASTER_AUTH_COOKIE_SIZE (128/8) /* LOGIN_MAX_INBUF_SIZE should be based on this.*/ -#define MASTER_AUTH_MAX_DATA_SIZE 1024 +#define MASTER_AUTH_MAX_DATA_SIZE 4096 #define MASTER_AUTH_ERRMSG_INTERNAL_FAILURE \ Internal error occurred. Refer to server log for more information. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] Auth worker max line size
Hi 38 month ago, I submitted a patch to increase AUTH_WORKER_MAX_LINE_LENGTH to use exotic authentication scheme (see message below). The patch was accepted, but now I upgrade to dovecot 2.1.7, I face the same problem with MASTER_AUTH_MAX_DATA_SIZE. I had to increase it from 1024 to 4096. Is it safe to do so? Would such a change be accepted upstream? The patch is below. (please Cc: me, I'm not subscribed ot the list) --- src/lib-master/master-auth.h.orig +++ src/lib-master/master-auth.h @@ -13,9 +13,9 @@ /* Authentication client process's cookie size */ #define MASTER_AUTH_COOKIE_SIZE (128/8) /* LOGIN_MAX_INBUF_SIZE should be based on this.*/ -#define MASTER_AUTH_MAX_DATA_SIZE 1024 +#define MASTER_AUTH_MAX_DATA_SIZE 4096 #define MASTER_AUTH_ERRMSG_INTERNAL_FAILURE \ Internal error occurred. Refer to server log for more information. Emmanuel Dreyfus m...@netbsd.org wrote: Hello I have been playing with some exotic authentication scheme with Dovecot and PAM. That involves sending really large base64 encoded data as the IMAP password, and I have hit a line limit in Dovecot, with AUTH_WORKER_MAX_LINE_LENGTH set to 1024. This limit is especially frustrating since other parts of the software use much larger limits: MAX_INBUF_SIZE 4096 MAX_IMAP_LINE 8192 AUTH_CLIENT_MAX_LINE_LENGTH 8192 I had to make the patch attached below to get my authentication working. I can live with this local patch, but given the much more liberal limits of MAX_INBUF_SIZE at 4096 makes we wonder if this 1024 limit on AUTH_WORKER_MAX_LINE_LENGTH could not be a bug. Or is there a security concern at using more than 1kB? Opinions? (please Cc: me, I'm not subscribed ot the list) --- src/auth/auth-worker-client.h.orig 2009-06-23 18:32:15.0 +0200 +++ src/auth/auth-worker-client.h 2009-06-23 18:32:33.0 +0200 @@ -1,8 +1,8 @@ #ifndef AUTH_WORKER_CLIENT_H #define AUTH_WORKER_CLIENT_H -#define AUTH_WORKER_MAX_LINE_LENGTH 1024 +#define AUTH_WORKER_MAX_LINE_LENGTH 4096 struct auth_worker_client *auth_worker_client_create(struct auth *auth, int fd); void auth_worker_client_destroy(struct auth_worker_client **client); void auth_worker_client_unref(struct auth_worker_client **client); -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] what best for anti-spam filter?
On Tue, Jul 24, 2012 at 03:38:00AM -0500, Stan Hoeppner wrote: Greylisting only stops bots. It is resource intensive, and causes delivery delays. There exist bot spam killing solutions that are just as effective, with less downside. Two are Postfix' postscreen daemon, and fqrdns.pcre, which rejects based on consumer/dynamic looking rDNS. I use that in order to decide the greylisting delay: suspect IP get a 12 hours greylist, everyone else gets 15 mn, or 0 if whitelisted by recipeients. It works quite well. -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] what best for anti-spam filter?
On Tue, Jul 24, 2012 at 10:49:48AM +0200, Morten Stevens wrote: No, greylisting is really a bad solution. It is not RFC compliant Of course it is. Have you readen RFC 6647? and delays the mail traffic. Greylisting with whitelist and reputation-based greylisting delay makes it painless. -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] what best for anti-spam filter? [greylisting]
On Tue, Jul 24, 2012 at 12:03:55PM +0200, Andrzej A. Filip wrote: Have you considered using some dnswl (whitelist) to turn off greylisting for some hosts? I do not do it, but it is trivial to configure milter-greylist for that usage: just add a whitelist acl based on a DNSRBL lookup. -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] what best for anti-spam filter?
Morten Stevens mstev...@imt-systems.com wrote: So it is now RFC compliant. Anyway I think delaying mail traffic is not a good solution. This is why whitelists and autowhilists are used in greylist filters. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] what best for anti-spam filter?
fy f...@5dshu.com wrote: what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ? milter-greylist of course :-) http://hcpnet.free.fr/milter-greylist/ Note that the name is a tribute to what it has been in the beginning, but we now have much more features than greylisting. IMO the really nice thing in milter-greylist is its ACL, which enable different filtering for different recipients. If you add a user-accessible report about what was filtered, then the users can enable/disable filters on the fly depending on their use, which brings to MTA filtering the interraction we used to have in MUA-based filtering. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [Dovecot] pop3-throttle
On Wed, Jun 27, 2012 at 12:50:20PM +0300, Timo Sirainen wrote: What mailbox format do you use? This shouldn't be a problem with for example mdbox, probably not with sdbox either and with mbox/maildir there are settings that can improve this. This is mbox. Or are you not talking about opening the mailbox, but about clients redownloading all the mails all the time? I don't think the client downloads the whole mailbox each time. It takes so long on a 1 GB mbox that the users would have complained. However, I can see a lot of disk I/O activity for pop daemon operating on the bigger mbox (easy to spot looking at the process uid) -- Emmanuel Dreyfus m...@netbsd.org
[Dovecot] pop3-throttle
Hello I am having a hard time with users using POP while leaving mailboxes of several gigabyte cumulated. This causes a lot of disk I/O and kills performancs for everyone. I try to encourage people migrating to IMAP, but that migration will take some time, and therefore I am looking for alterantive ways to workaround the problem. I found pop3-throttle-plugin.c, which seems a smart way to solve the problem, unfortunately it comes with no documentation. I was able to build it and load it, bu itsays nothing in the logs. Is there any doc somewhere? Any advices on how to set it up? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
[Dovecot] Auth worker max line size
Hello I have been playing with some exotic authentication scheme with Dovecot and PAM. That involves sending really large base64 encoded data as the IMAP password, and I have hit a line limit in Dovecot, with AUTH_WORKER_MAX_LINE_LENGTH set to 1024. This limit is especially frustrating since other parts of the software use much larger limits: MAX_INBUF_SIZE 4096 MAX_IMAP_LINE 8192 AUTH_CLIENT_MAX_LINE_LENGTH 8192 I had to make the patch attached below to get my authentication working. I can live with this local patch, but given the much more liberal limits of MAX_INBUF_SIZE at 4096 makes we wonder if this 1024 limit on AUTH_WORKER_MAX_LINE_LENGTH could not be a bug. Or is there a security concern at using more than 1kB? Opinions? (please Cc: me, I'm not subscribed ot the list) --- src/auth/auth-worker-client.h.orig 2009-06-23 18:32:15.0 +0200 +++ src/auth/auth-worker-client.h 2009-06-23 18:32:33.0 +0200 @@ -1,8 +1,8 @@ #ifndef AUTH_WORKER_CLIENT_H #define AUTH_WORKER_CLIENT_H -#define AUTH_WORKER_MAX_LINE_LENGTH 1024 +#define AUTH_WORKER_MAX_LINE_LENGTH 4096 struct auth_worker_client *auth_worker_client_create(struct auth *auth, int fd); void auth_worker_client_destroy(struct auth_worker_client **client); void auth_worker_client_unref(struct auth_worker_client **client); -- Emmanuel Dreyfus m...@netbsd.org
Re: [Dovecot] Auth worker max line size
On Wed, Jun 24, 2009 at 02:21:50PM -0400, Timo Sirainen wrote: There's no real reason to keep it at 1 kB. I probably didn't even think about it much when I added it. I increased it to 8192 now. Thanks a lot! -- Emmanuel Dreyfus m...@netbsd.org
