Replication to wrong mailbox

[Ralf Becker]

Hi Aki,

Am 02.11.17 um 09:57 schrieb Aki Tuomi:
> Can you somehow reproduce this issue with auth_debug=yes and
> mail_debug=yes and provide those logs?

I will try, knowing now someone will look at the logs.

It might take a couple of days. I'll come back once I have the logs.

Ralf

> Aki
>
>
> On 02.11.2017 10:55, Ralf Becker wrote:
>> No one any idea?
>>
>> Replication into wrong mailboxes caused by an unavailable proxy dict
>> backend is a serious privacy and/or security problem!
>>
>> Ralf
>>
>> Am 30.10.17 um 10:05 schrieb Ralf Becker:
>>> It happened now twice that replication created folders and mails in the
>>> wrong mailbox :(
>>>
>>> Here's the architecture we use:
>>> - 2 Dovecot (2.2.32) backends in two different datacenters replicating
>>> via a VPN connection
>>> - Dovecot directors in both datacenters talks to both backends with
>>> vhost_count of 100 vs 1 for local vs remote backend
>>> - backends use proxy dict via a unix domain socket and socat to talk via
>>> tcp to a dict on a different server (kubernetes cluster)
>>> - backends have a local sqlite userdb for iteration (also containing
>>> home directories, as just iteration is not possible)
>>> - serving around 7000 mailboxes in a roughly 200 different domains
>>>
>>> Everything works as expected, until dict is not reachable eg. due to a
>>> server failure or a planed reboot of a node of the kubernetes cluster.
>>> In that situation it can happen that some requests are not answered,
>>> even with Kubernetes running multiple instances of the dict.
>>> I can only speculate what happens then: it seems the connection failure
>>> to the remote dict is not correctly handled and leads to situation in
>>> which last mailbox/home directory is used for the replication :(
>>>
>>> When it happened the first time we attributed it to the fact that the
>>> Sqlite database at that time contained no home directory information,
>>> which we fixed after. This first time (server failure) took a couple of
>>> minutes and lead to many mailboxes containing mostly folders but also
>>> some new arrived mails belonging to other mailboxes/users. We could only
>>> resolve that situation by rolling back to a zfs snapshot before the
>>> downtime.
>>>
>>> The second time was last Friday night during a (much shorter) reboot of
>>> a Kubernetes node and lead only to a single mailbox containing folders
>>> and mails of other mailboxes. That was verified by looking at timestamps
>>> of directories below $home/mdbox/mailboxes and files in $home/mdbox/storage.
>>> I can not tell if adding the home directory to the Sqlite database or
>>> the shorter time of the failure limited the wrong replication to a
>>> single mailbox.
>>>
>>> Can someone with more knowledge of the Dovecot code please check/verify
>>> how replication deals with failures in proxy dict. I'm of cause happy to
>>> provide more information of our configuration if needed.
>>>
>>> Here is an exert of our configuration (full doveconf -n is attached):
>>>
>>> passdb {
>>>   args = /etc/dovecot/dovecot-dict-master-auth.conf
>>>   driver = dict
>>>   master = yes
>>> }
>>> passdb {
>>>   args = /etc/dovecot/dovecot-dict-auth.conf
>>>   driver = dict
>>> }
>>> userdb {
>>>   driver = prefetch
>>> }
>>> userdb {
>>>   args = /etc/dovecot/dovecot-dict-auth.conf
>>>   driver = dict
>>> }
>>> userdb {
>>>   args = /etc/dovecot/dovecot-sql.conf
>>>   driver = sql
>>> }
>>>
>>> dovecot-dict-auth.conf:
>>> uri = proxy:/var/run/dovecot_auth_proxy/socket:backend
>>> password_key = passdb/%u/%w
>>> user_key = userdb/%u
>>> iterate_disable = yes
>>>
>>> dovecot-dict-master-auth.conf:
>>> uri = proxy:/var/run/dovecot_auth_proxy/socket:backend
>>> password_key = master/%{login_user}/%u/%w
>>> iterate_disable = yes
>>>
>>> dovecot-sql.conf:
>>> driver = sqlite
>>> connect = /etc/dovecot/users.sqlite
>>> user_query = SELECT home,NULL AS uid,NULL AS gid FROM users WHERE userid
>>> = '%n' AND domain = '%d'
>>> iterate_query = SELECT userid AS username, domain FROM users


-- 
Ralf Becker
EGroupware GmbH [www.egroupware.org]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 631 31657-0




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://dovecot.org/pipermail/dovecot/attachments/20171102/dfee61b6/attachment-0001.sig>