Print this Page

using postfix and dovecot to provide mail to egroupware

This document describes how to configure postfix and dovecot with egroupware on a single server. If the egroupware installation is to be used at the end of a domestic ADSL line, then you may care to read one of my earlier posts about postfix (“upstream authentication with tls on postfix“) which describes how to configure that MTA to relay securely to an upstream server.

egroupware is a PHP based web application which offers users mail, calendars, file sharing, address books, a wiki and other useful facilities such as project management, timesheets and resource (think room booking) management tools. It is a fairly powerful suite of applications and is really aimed at so called “enterprise” installations. I chose to use it to provide filesharing, webmail, diary, news and directory services for a networking group. One of the nice features of the suite is its potential for providing virtual mail services to multiple domain users. In order to do this, however, it needs to be integrated with an MTA capable of handling virtual mail domains and an IMAP/POP server for local mail delivery. Postfix and dovecot are ideal and they work together well.

Step 1 – Postfix configuration for Dovecot

First we need need to get postfix and dovecot working together. The postfix configuration required is very straightforward and simply needs the addition of a few new lines to main.cf and master.cf – thus:

in file /etc/postfix/main.cf

transport_maps = hash:/etc/postfix/transport
dovecot_destination_recipient_limit = 1
virtual_mailbox_domains = domain.com
virtual_transport = dovecot

This tells postfix to allow relaying to the vitual domain(s) listed and to use dovecot as the transport mechanism for the virtual domain(s). The transport database simply contains one line for each virtual domain to be handled by dovecot – thus:

in file /etc/postfix/transport

domain.com dovecot:

As is usual when configuring postfix, don’t forget to regenerate the transport database file by running “postmap transport”.

Rather than letting postfix deliver mail to virtual user mailboxes, I found it better to use dovecot as the local delivery mechanism. This allowed me to simply hand off incoming mail for virtual users to dovecot and let it figure out which mailbox the mail should be stored in. See the dovecot documentation wiki for a description of how this works. The dovecot LDA, called “deliver”, is a local delivery agent which takes mail from any MTA and delivers it to the correct user’s mailbox, while keeping dovecot index files up to date. The key to doing this with postfix is to add add a dovecot service in /etc/postfix/master.cf – thus:

dovecot unix – n n – – pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}

Note that the dovecot documentation suggests that you can use “deliver” for all system users on a single domain mail host by editing the “mailbox_command” parameter in main.cf -thus:

mailbox_command = /usr/local/libexec/dovecot/deliver (actually usr/lib/dovecot/deliver on a debian system)

I chose not to do this because I wanted to continue to accept mail locally on the postfix host for mail actually aimed at the default domain for that host. This allows me to accept mail for one or two local users @localdomain.com and deliver the mail to mailboxes in the standard /var/mail/user form whilst using dovecot to deliver mail for virtual users to /var/vmail/virtualuser.

Having configured postfix. we now need to modify the default docvecot.conf file and create a configuration file for the SQL connection to the egroupware database.

Step 2 – Dovecot configuration

The dovecot configuration file contains many default options which may be left unchanged. My configuration file looks like this:

## Dovecot configuration file

protocols = imap pop3s

log_timestamp = “%Y-%m-%d %H:%M:%S ”
syslog_facility = mail
mail_privileged_group = mail

disable_plaintext_auth = yes

first_valid_uid = 500
last_valid_uid = 65535

first_valid_gid = 500
last_valid_gid = 65535

protocol imap {
listen= localhost:143
}

protocol pop3 {
listen = 192.168.30.40:995
pop3_uidl_format = %08Xu%08Xv
}

protocol lda {
postmaster_address = postmaster@localdomain.com
hostname = smtp.localdomain.com
auth_socket_path = /var/run/dovecot/auth-master
}

#ssl_listen =

ssl_disable = no

ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem

#ssl_key_password =

#ssl_ca_file =

ssl_verify_client_cert = no

ssl_parameters_regenerate = 168

ssl_cipher_list = TLSv1+HIGH !SSLv2 !RC4 !aNULL !eNULL !3DES @STRENGTH

verbose_ssl = no

auth default {
mechanisms = plain

userdb passwd {
args = mail=mbox:/var/mail
}

passdb pam {
args = dovecot
}

userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}

passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}

socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
group = vmail
}
}
}

# end dovecot configuration

Note that I chose to use POP3S as well as IMAP (for egroupware mail) because I wanted to be able to pick up my egroupware account mail with my preferred POP client (Claws mail) on my desktop machine rather than have to log in to egroupware just for the mail. I also use POP3 to pick up local system user mail on that machine.

There is little danger in using the login method “plain” because IMAP connections are limited to localhost only and remote POP3 connections are made over SSL. Furthermore, the setting “disable_plaintext_auth = yes” prevents remote logins with plain text authentication unless that connection is made over SSL.

The values chosen for “first_valid_uid” and “first_valid_gid” were picked solely to ensure that no system or daemon UIDs can be used – YMMV.

The userdb passwd and passdb pam config options allow me to authenticate local system users against system files, whilst the userdb sql and passdb sql options are essential for us to be able to authenticate egroupware users against the mysql database backend. The “args = mail=mbox:/var/mail” line for userd passwd means that we are using mbox format mailboxes in the system directory /var/mail (default for debian) whilst the “args = /etc/dovecot/dovecot-sql.conf” line for userdb sql means that there is additional configuration to be found in that file.

My dovecot-sql.conf file looks like this:

# dovecot-sql.conf

driver = mysql

connect = host=localhost dbname=egroupware user=egroupware password=some-password

default_pass_scheme = PLAIN-MD5

user_query = SELECT 500 AS uid, 500 AS gid, ‘/var/vmail/%u’ AS home FROM egw_accounts where account_lid = ‘%u’

password_query = SELECT account_pwd AS password FROM egw_accounts WHERE account_lid = ‘%u’

# end dovecot-sql.conf

This configuration file relies on some details about the egroupware database structures which are not well documented. The critical elements are:

mysql database name = egroupware (this is the default unless you changed it on setup – in which case you know what it is!).
mysql database username = egroupware (again the default)
mysql database password = whatever you set

mysql database table holding account details = egw_accounts
full account name = account_lid
numeric account id = account_id
password = account_pwd

The connect statement allows us connect to the egroupware database with the correct user and password (set during the egroupware configuration). The user_query line allows us to select the user details from the database table “egw_accounts” where the egroupware user account name (“account_lid”) is the userid passed as %u. Note that I force some parameters to be static for all users – notably I use the same uid/gid (500) for all users. I created the user/group “vmail” with uid/gid = 500 for this purpose. That user has its home directory set to /var/vmail in /etc/passwd. This allows me to force the home directory for all virtual mail users to be /var/vmail with users’ individual mail stored in subdirectories named after the account. Password authentication is done against the database by checking the value held in the “account_pwd” field in the “egw_accounts” table.

Step 3 – egroupware configuration

Installation of egroupware is reasonably straightforward. If you install from the source provided on the egroupware download site you will get the latest (currently 1.6) release. The site offers RPM bundled packages if you happen to use Suse or Redhat/Fedora or any other RPM based distro. I prefer Ubuntu and Debian and built my installation on a Debian server so I installed from the Debian repository (purely for convenience). This means that my installation is based on the earlier 1.4 release, but the differences are not significant enough to affect this description. Using a package manager also avoids some of the dependency problems you can face when installing from source, though egroupware has few external dependencies beyond the obvious webserver, DBM and PHP. Most people will use the standard LAMP stack. I chose to use lighttpd rather than apache – largely because I have come to prefer that server. I used to be a big apache fan, but it now strikes me as becoming overly large and complicated. As I have mentioned before, lighttpd has a remarkably small memory footprint – I use it on my slugs.

The egroupware site has a good description of how to install the package, so I won’t go into any detail here. The relevant configuration options for the egroupware email system can be found in “admin” -> “emailadmin” -> “site configuration” on the administrator’s page. The options I set were the relatively simple:

smtp server type = standard smtp server
smtp server hostname or IP address = localhost
smtp port = 25.

I left the SMTP auth section blank as I do not use authentication on the local SMTP server. If using a remote SMTP server it might be a good idea to use authentication. For the IMAP server configuration I again set some fairly standard choices:

IMAP server type = standard IMAP server
server hostname or IP address = localhost
IMAP server port = 143
IMAP server login type = username(standard).

Some useful resources

I found the following sites helpful when researching how best to configure the various components of this system

postfix configuration
dovecot wiki on local delivery
dovecot authentication
dovecot and postfix with PAM authentication
installing egroupware

Permanent link to this article: http://baldric.net/using-postfix-and-dovecot-to-provide-mail-to-egroupware/