I already showed here what virtual users are and what they can be used for The goal of this page is „just“ to implement the virtual users feature into dovecot (IMAP/POP3) server

Unfortunately virtual user support for dovecot require slight more effort than those is postfix-only. The main „thing“ is to compile the so called LDA (Local Delivery Agent) named deliever ¹⁾. This is a proccess for dovecot. deliver is not included and therefore need to e compiled from source directly on your diskstation.

First the same requirements exists as for Dovecot Sieve. Get the packages listed there and install them on your DS (sources for dovecot-sieve ARE NOT needed!). After the necessary un-packing, change to the extracted directory. First compile dovecot and then install deliver.

Open the file /usr/syno/mailstation/etc/dovecot.conf in an editor like vi oder nano. Look for the string protocol lda { Per default this feature is „commented“ so remove # and scroll down until the first line } appears. Remove # too.

One of the last lines before the closing } is auth_socket_path = /var/run/dovecot/auth-master. Remove comment there too. This master-daemon will e used by deliver to authenticate users. Direclty after the closing } of protocol lda ensure that the following line is present auth_executable = /usr/syno/mailstation/libexec/dovecot/dovecot-auth

Scroll down more until you find auth default { Within this directive there should be an entry like

passdb passwd-file {
    # File contains a list of usernames, one per line
    args = /opt/etc/dovecot/passwd
    #deny = yes
  }

The passwd MUST belong to root und MSUT ONLY have rights for owner (no group rights!!)

 chmod 0600 /opt/etc/dovecot/passwd && chown root /opt/etc/dovecot/passwd

Scroll further until you see userdb static { This defines the homedirs of the virtual users. Paths with variable substitution are possible

args = uid=vmail gid=vmail home=/volume1/homes/vmail/%d/%n

code above defines the local user vmail and the local group vmail to be used for all mail transactions from virtual users (this user can be created with DSM, name is not fixed you can choose anything you want). Then the homes are defined to have as base vmails homedir. In its home a folder for each domain is expected, followed by a folder for each user for the domain. This helps to keep order in the mails

Example: If a mail for user@domain.tld arrives then dovecot will take /volume1/homes/vmail/domain.tld/user as users home and look in there for .Maildir

Now look for the string socket listen { There should be a auth process as first element

master {
      path = /var/run/dovecot/auth-master
      mode = 0666
    }

This will e the master proccess deliver uses for user authentification. With these steps the configuration is „almost“ finished.

But just almost A further little config makes the dovecot authentification available for postfix SASL as well Following the master proccess there should be a client proccess

client {
      path = /var/spool/postfix/private/auth
      mode = 0660
      user = postfix
      group = postfix
    }

user and group postfix do already exists on the DS. So if postfix need to authenticate a user „he“ will ask via the defined client to dovecot. If you do postfix auth as well with dovcot then no virtual_mailbox_domains and virtual_mailbox_maps setting in /usr/syno/mailstation/etc/main.cf

To let postfix know to make use of doveot for auth some changes to the postfix files are necessary too. First create a new line in /usr/syno/mailstation/etc/main.cf

virtual_transport = dovecot

This leads postfix to look in /usr/syno/mailstation/etc/master for a service called dovecot which we create with the following line

dovecot	unix	-	n	n	-	-	pipe
 flags=DRhu user=vmail:vmail argv=/usr/syno/mailstation/libexec/dovecot/deliver -f ${sender} -d ${user}@${nexthop}

This line requires user vmail and group vmail to be present and that deliver exists in the defined path

After that

/usr/syno/mailstation/sbin/postfix reload

After deliver is installed and running you should change the rc files for getmail in order getmail uses deliver for mail delivery and does not put them directly to the users mailbox.

[destination]
type = MDA_external
path = /usr/syno/mailstation/libexec/dovecot/deliver
arguments = ("-d","user@domain.tld",)

To create virtual users you should install dovecotpw as well. It's sources are in src/util (or see alternative below)

make install dovecotpw

and copy the files created into a folder within PATH.
After that the following command creates a user user@domain.tld with password totalSecret hashed with a SSHA in given file

echo user@domain.tld:$(dovecotpw -p "totalGeheim" -s SSHA) >> /opt/etc/dovecot/passwd

After that you'll have to create the following directories

mkdir -p /volume1/homes/vmail/domain.tld/user/.Maildir
chown -R vmail:vmail /volume1/homes/vmail
chmod -R g-rwx,o-rwx /volume1/homes/vmail

An alternative to compiling dovecotpw from source would be the following steps

mkdir /volume1/public/tmp
cd /volume1/public/tmp
ipkg download dovecot
mv dovecot_1.2.0.beta1-2_powerpc.ipk dovecot_1.2.0.beta1-2_powerpc.tar.gz
tar xvzf dovecot_1.2.0.beta1-2_powerpc.tar.gz
tar xvzf data.tar.gz
cp ./opt/sbin/dovecotpw /usr/syno/mailstation/libexec/dovecot/
rm -R /volume1/public/tmp

Mailprocessing via a LDA is quite sensitive to access right issues on Mailboxes and Userhomes. As a first step with problems you should ensure that the homedir (in this case /volume1/homes/vmail) has only rights for owner and belongs to vmail.

chown -R vmail /volume1/homes/vmail
chmod -R g-rwx,o-rwx /volume1/homes/vmail

Furthermore it can be very helpful for debugging to install an alternative syslog daemon (like ipkg syslog-ng). It offers a wide range for customization. Can be extremly helpful with mailserver issues

Dovecot offers a lot of config options in dovecot.conf. A lot of these options allow dovecot to log into files directly. Although not for productive systems, it can be very helpful for debugging.

A tipp for spamassassin. If you get all your mails via the „central“ user (vmail), then you should ensure that the child process of spamassassin is running under that user as well. That way file permissions should always match!