dovecot - Feb 2017 - pop3 and dsync master-master replication issue causing duplicate delivery (resolved)

I had opened a thread a while ago in regards to dsync duplicate delivery issues.
Here is an update in case anybody else is suffering from this:


https://dovecot.org/list/dovecot/2016-April/103973.html


We are using an LDAP backend for userdb and passdb lookups and this is causing
multiple replication users to be created. Here is the broken setup:


###############################################

userdb

###############################################

hosts = localhost
dn = cn=dovecot,dc...
dnpass = PASSWORD
ldap_version = 3
base = ou=instances,dc...
deref = never
scope = subtree
user_attrs = \
  =home=/mail/spool/hash-%0.2M{ldap:uid}/%{ldap:uid}, \
  =mail=maildir:/mail/spool/hash-%0.2M{ldap:uid}/%{ldap:maildrop}
user_filter = (&(objectClass=mailUser)(uid=%n))
iterate_attrs = uid=user
iterate_filter = (objectClass=mailUser)
###############################################

passdsb

###############################################

hosts = localhost
dn = cn=dovecot,dc=dc...
dnpass = PASSWORD
ldap_version = 3
base = ou=instances,dc=dc...
deref = never
scope = subtree
pass_attrs = uid=user,userPassword=password, \
  =userdb_home=/mail/spool/hash-%0.2M{ldap:uid}/%{ldap:uid}, \
  =userdb_mail=maildir:/mail/spool/hash-%0.2M{ldap:uid}/%{ldap:maildrop}
pass_filter = (&(objectClass=mailUser)(uid=%n))

###############################################


If you don't specify a user attribute in the userdb configuration, dovecot
uses the destination email address to create the replication user in addition to
users based on the definitions from iterate_attr and pass_attr entries. At the
end, multiple replication users are created for the same mailbox causing deleted
messages to re-appear and get delivered multiple times.


###############################################

username                             priority fast sync full sync failed
buraktest1                               none     02:07:02  02:07:02  -
buraktest1 at buraktest1.domain.com        none     02:57:13  02:57:13  -
###############################################


One thing to note here is that the behavior does not manifest itself during the
first delivery/retrieval/delete cycle. You need to repeat the cycle again to
expose the issue.


The fix is to define and override the "user" attribute in the userdb
configuration:


###############################################

userdb

###############################################

hosts = localhost
dn = cn=dovecot,dc...
dnpass = PASSWORD
ldap_version = 3
base = ou=instances,dc...
deref = never
scope = subtree
user_attrs = \
  =user=%{ldap:uid}, \
  =home=/mail/spool/hash-%0.2M{ldap:uid}/%{ldap:uid}, \
  =mail=maildir:/mail/spool/hash-%0.2M{ldap:uid}/%{ldap:maildrop}
user_filter = (&(objectClass=mailUser)(uid=%n))
iterate_attrs = uid=user
iterate_filter = (objectClass=mailUser)
###############################################