Dovecot

Table of Contents

Foreword by Timo Sirainen

Preface

1. Protocols and Terms

1.1. An Overview of Terms

1.2. What makes IMAP so complex?

I. Dovecot for all purposes

2. Installation

2.1. Installation under Debian/Ubuntu

2.2. Installation under openSUSE/SLES

2.3. Installation under CentOS/RHEL

2.4. Starting Dovecot for the first time

2.5. The first login

3. POP3 and IMAP at protocol level

3.1. POP3

3.1.1. Test-session

3.2. IMAP

3.2.1. Design of the IMAP-protocol

3.2.2. Description of an IMAP session

3.2.3. IMAP in practical terms

3.2.4. Subscribing to IMAP folders

4. Introduction to the configuration

4.1. The doveconf tool

4.2. Where and how to store your local configuration

4.3. Activating log messages

4.4. Specifying the IMAP namespace

4.4.1. The right hierarchy separator

4.4.2. Choosing the folder prefix

4.4.3. Standardized names for trash, sent & Co.

5. Authentication

5.1. Basic settings

5.2. Authentication sources

5.3. /etc/passwd & /etc/shadow

5.4. passwd-file

5.5. LDAP queries/active directory

5.5.1. To begin with: LDAP analysis with ldapsearch

5.5.2. Configuration of password lookups (OpenLDAP)

5.5.3. Configuration of authenticated binds (Active Directory, OpenLDAP)

5.5.4. Setting LDAP search filters for userdb and passdb requests

5.6. SQL databases

5.7. Performance optimization: prefetching with LDAP or SQL

5.8. Different or identical UIDs?

5.9. How not (!) to assign UID, GID and HOME

5.10. Saving passwords: plain text or hash?

5.10.1. Authentication methods PLAIN/LOGIN

5.10.2. Authentication methods CRAM/DIGEST

5.10.3. Setting up the CRAM process in Dovecot

5.10.4. PLAIN/LOGIN only secure via SSL/TLS

5.10.5. How password hashes are saved

5.10.6. Login name or email address as login?

5.10.7. Practical suggestion: different userdb and passdb queries!

5.11. Master user

5.12. Some extras

5.12.1. Passdb extra fields

5.12.2. Userdb extra fields

5.13. A list of all users – the iterate query

6. How to configure Postfix as a relay in front of Dovecot

6.1. Delivery via dovecot-lda

6.2. Delivery via Dovecot via LMTP

6.3. Configuration

6.4. What recipients are there? Dynamic recipient verification

6.5. Setting up SMTP-Auth in Postfix

6.6. Less is more: do not go via Postfix

6.7. Advanced information on the configuration of Postfix

7. mbox, Maildir and mdbox: a comparison of storage formats

7.1. Overview of the three formats

7.2. Maildir as an email storage format

7.2.1. Technical structure of Maildir

7.2.2. File names of emails

7.2.3. Keywords: custom IMAP flags

7.3. mdbox: the new format for larger setups

7.3.1. Why mdbox is faster

7.3.2. Configuration of mdbox

7.3.3. Making space: doveadm purge

7.3.4. ALT storage: fast and slow data storage combined

7.4. zlib compression on the fly: faster and more space-saving

7.5. auto: migration of storage formats during live operation

7.5.1. auto: parallel operation of multiple storage formats

7.5.2. A solid migration script as an example

8. Partitions, file systems and downtimes during the file system check

8.1. /srv/mail as data partition

8.1.1. Email data in a separate subdirectory

8.1.2. Email data on a separate data partition

8.1.3. doveadm mount: in case something is missing

8.2. Choosing the right file system

8.3. Measuring performance

8.4. Performance tuning the file system

8.4.1. atime

8.4.2. The journal mode in ext3/ext4

8.4.3. Optimized fstab entries

8.5. Out of service thanks to fsck

II. Advanced Dovecot Installation

9. The IMAP namespace and shared folders

9.1. Necessary preparation

9.2. Definition of a shared namespace

9.3. The right hierarchy separator for a shared namespace

9.4. Shared folders in mdbox or the auto:-mode

9.5. Folders parallel to the INBOX

9.6. Public folders

9.6.1. Managing the public namespace with a dummy user

9.6.2. Display in the folder listing

9.7. User-specific \Seen flags in shared folders and in the public namespace

10. Setting up SSL and TLS

10.1. How SSL/TLS works

10.2. How to generate a self-signed key

10.3. Different keys for different IPs

10.3.1. Different keys for different services

10.3.2. Different keys on different IPs

10.3.3. Server Name Indication (SNI)

10.4. SSL/TLS and authentication

11. Quotas

11.1. Structure of a quota system

11.2. Quota backends

11.3. Activating the quota plugin

11.4. Configuring quota roots and the quota backend

11.5. Definition of the quota rules

11.6. How to create quota warnings for users

11.7. Individual quota messages

11.8. User-specific quotas

11.8.1. passwd file

11.8.2. LDAP

11.8.3. MySQL

11.8.4. PostgreSQL or SQLite

11.9. Multiple quota roots

11.10. Working with quotas: doveadm quota

11.11. Introducing quotas in large systems

11.11.1. Medium-sized systems with no more than 500 users

11.11.2. Large systems with more than 500 users

11.12. The Quota policy server for Postfix

12. Server-side email filtering with Sieve

12.1. Setting up Sieve

12.2. Out of office response via Sieve script

12.3. Converting old procmail scripts

12.4. Applying Sieve scripts to emails that have already been received

13. Email extensions

13.1. The recipient delimiter extends email addresses

13.2. Automatic saving of emails in IMAP folders

14. Daily maintenance of the email storage with doveadm

14.1. General operation of doveadm

14.2. Managing IMAP folders

14.2.1. Creating, renaming and deleting folders

14.2.2. Converting special characters in folder names

14.2.3. Querying the status and number of emails in a folder

14.2.4. Subscribing to folders

14.3. Searching for emails

14.3.1. Directory of all possible search keys

14.3.2. Dates in search criteria

14.3.3. Sizes in search criteria

14.3.4. Extracting emails as the result of a search

14.3.5. Moving and copying emails

14.4. Exporting mailboxes to a target directory or synchronizing them with the directory

14.5. Backup and recovery

14.6. Repairing an index

14.7. References to other topics

15. Performance tuning for more than 1000 simultaneous logins

15.1. Increasing the maximum number of clients

15.2. Reducing login processes

15.3. Increasing the file handles

15.3.1. Debian/Ubuntu

15.3.2. openSUSE/SLES

15.3.3. CentOS/RHEL

15.4. Push email and IDLE

15.5. Using the write cache in the mail storage

15.6. Single instance storage for attachments

16. Load-balancing cluster

16.1. Active/passive cluster

16.2. Partitioned clusters with Dovecot proxy

16.3. Active/active cluster with Dovecot Director

16.3.1. The Dovecot Director

16.3.2. Director management during runtime

16.4. Active/active cluster with real-time replication

16.4.1. Replication on the basis of doveadm via TCP/IP

16.4.2. Replication of a public namespace

16.4.3. Securing via SSL

16.4.4. Replication on the basis of SSH logins

16.4.5. Monitoring and maintenance with doveadm replicator

16.4.6. Other things you need to consider

17. Autoconfig and Autodiscover – automatic configuration of email clients

17.1. Autoconfig with Thunderbird

17.2. Autodiscover with Outlook

17.3. Automatic configuration for Mac OS, iOS and Windows LiveMail

17.4. Dynamic configuration scripts in PHP and Python

18. Webmailer as a complementary service

18.1. Squirrelmail and Horde/IMP

18.2. Roundcube

18.2.1. Installation

18.2.2. Configuration

18.3. up-imapproxy – fast access through session caching

19. Migrating IMAP servers

19.1. Different ways to migrate a mail server

19.1.1. Migrations at file level

19.1.2. Migrations using the POP3/IMAP protocol

19.2. Migration with imapsync

19.3. Transparent migrations with imapc

19.4. Changes to folder names

19.5. Determining plain text passwords

20. Enterprise features and support

20.1. obox: Dovecot object storage

20.2. Configuration of various object storages

20.3. Future prospects

III. Appendix

A. doveadm – the Finnish army knife

B. IMAP command reference

B.1. IMAP commands available at any time

B.2. Commands in the not-authenticated state

B.3. Commands in the authenticated state

B.4. Commands in the Selected state

B.5. IMAP extensions

B.6. Experimental commands

C. POP3 command reference

C.1. An overview of all commands

C.2. Optional commands

D. The Sieve script language

D.1. Linking conditions

D.2. Overview of the various Sieve conditions

D.3. Match types for header and address

D.4. Sieve actions

Index

Peer Heinlein

Dovecot

POP3/IMAP servers for enterprises and ISPs

Open Source Press

The information in this book ist distributed on As is basis, without warranty. While every precaution has been taken in the preparation of this work, neither the authors nor the editors nor Open Source Press GmbH shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

Open Source Press and the Open Source Press logo are registered trade marks of Open Source Press GmbH. Other product or company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

Original German edition © 2014 Open Source Press, Munich

Peer Heinlein: Dovecot - POP3/IMAP-Server für Unternehmen und ISPs

Bibliographic information published by the Deutsche Nationalbibliothek

The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available in the Internet at http://dnb.dnb.de.

Copyright © 2014 Open Source Press GmbH

Editor: Markus Wirtz

Typesetting: textovia web application (textovia.com)

Graphic Designer: Olga Saborov

ISBN: 9783955391096 (E-Book EPUB) http://www.opensourcepress.de

Foreword by Timo Sirainen

It’s been about 11 years now since I first started Dovecot development. Back then, I was working for a small company where we needed an IMAP server for our emails. I was the only guy there with Linux experience, so besides doing the actual coding I was hired for, I was also the sysadmin. I’m not really sure what other people would have done in my situation, but I’m definitely not very good sysadmin material. I didn’t start by evaluating features of different open source IMAP servers, I started by evaluating their source code. I didn’t like any of them. I finally ended up with Courier, but I immediately decided I could do something better and started thinking about it. A few months later, I had the first public Dovecot release out.

Since then, it’s been pretty interesting and fun. For a long time I was working on Dovecot just in my free time. Sometimes on company time too, on behalf of various businesses. Eventually, several companies hired me directly to develop some new features for them. Rackspace hired me to work on-site for a year and Portugal Telecom for half a year. It was fun seeing how people live outside of Finland.

Developing Dovecot has always been kind of fun but sometimes also very frustrating, especially before the v1.0 release. For years I thought that Dovecot was usable for most people, but then bigger and bigger installations started using it and they kept finding more and more problems. At one point, I realized that the entire design was completely wrong, so I had to spend a couple of years rewriting the entire indexing code. Luckily, this turned out to be one of the main reasons for Dovecot’s good performance today.

Soon I started wondering what to do with the rest of my life after Portugal. Since I couldn’t really think of anything else, I finally decided to start my own Dovecot support company. I had been thinking about it already for over 5 years at least, but I didn’t have the right people to help manage and push me into it. Luckily, an old friend of mine was just thinking about moving into new things, and he decided it was the perfect time to start the Dovecot company with me.

A couple of people were really upset that Dovecot was now becoming commercialized and that I should never write anything about my company to the Dovecot mailing list, but the majority seemed to be happy enough. One of my main goals with the company has always been to think about Dovecot’s future. As I once mentioned in a customer meeting, I’ve only had one baby so far, and he’s a 10-year-old named Dovecot. I wouldn’t give him up for any amount of money. I want him to grow up old and take over the world. So the Dovecot company’s job is to make sure that it happens, and this requires a way to make money and hire more Dovecot developers. Our original idea of providing support and consulting around Dovecot didn’t start out too badly, but we later noticed it could never be enough to sustain the quick growth and improvements that we foresaw for Dovecot. We had to figure out a few other incentives for companies to give us money, which was the start of a few closed source components to Dovecot.

This book and especially its timing marks an interesting turning point in Dovecot’s life. It’s not quite what it used to be, and hopefully it will become much better in the near future at a much faster pace. Peer first asked me to give a Dovecot talk for his 3rd mail server conference in 2007, but at that point in my life I really didn’t want to give any Dovecot talks. But soon afterward I was more or less forced to do a few talks to some small crowds anyway, so I felt more comfortable giving my first public Dovecot talk at the next mail server conference.

Peer was already back then talking about just finishing his Cyrus/Courier/Postfix book and about adding Dovecot for the next one. It’s now several years later, but I think it’s the perfect time for this book to emerge!

Dovecot is still being developed at a fast pace, but there are no huge incompatible changes just around the corner, so this book should be useful for many more years to come.

Finally, I’d like to give thanks to everyone who has helped Dovecot become as awesome as it is today.

Timo Sirainen

January 2014, Helsinki/Finnland

Preface

I am happy to admit it: when I first heard 10 years ago that a new IMAP server called Dovecot was under development, I thought it was absolutely superfluous. There were Courier and Cyrus, both of which had their own areas of application, and it made no sense to me to introduce a third instead of developing Courier further. All the more as the first versions of Dovecot were very similar to Courier and were not able to cover the same range of functions. Then there were the usual launch difficulties and bugs, with the new software refusing to do what it is supposed to.

But soon (after a very short time) it became clear that Dovecot was catching up with Courier and Cyrus – and had even overtaken them. The scope of functions in Dovecot was far wider, the speed faster, the configuration clearer and more flexible, and the log file easier to read. In addition, Dovecot was RFC-conform, and the developers were introducing new features every week that brought joy to an admin’s heart. In short, Dovecot is (and was) fun. And I know what I’m talking about, because I have already published an IMAP book about Cyrus and Courier that Dovecot has made obsolete. This book would like to be its worthy successor.[1]

For me there is no question about which IMAP server to use. Since version 2.x at the latest, Dovecot has been far superior to all the other candidates. Courier has no right to exist any more, and Cyrus is not much better. Dovecot versions 2.2.x provide options (in the cluster area, for example) that Cyrus admins would not dare to dream of.

According to measurements conducted in June 2013 by http://openemailsurvey.org/, Dovecot is far in front with more than 2.3 million installations and a diffusion rate of over 50%.

Most Cyrus administrators do not even know what they are missing. In my work as a consultant and trainer, I keep meeting people who defend Cyrus vehemently and are skeptical of Dovecot. As they learn a little more about Dovecot in their first hour of training, they start to get a little envious. After 2 hours, they start to get thoughtful – and after 3 hours, they get excited, but about Dovecot rather than Cyrus.

When the first day is over, even skeptics are usually determined to migrate to Dovecot – even though the truly interesting features have not even been discussed at that stage.

Dovecot is an outstanding IMAP server for all sizes.

It is properly programmed and RFC-conform (Cyrus is not).

It provides all the features you could want, such as quotas (Chapter 11), shared folders (Chapter 9) and Sieve filtering (Chapter 12).

Its basic configuration allows plenty of performance tuning and improvements, so there is no need to bludgeon load problems with hardware (Chapter 15).

It contains a powerful command line tool, doveadm, that you can use to automate almost every tasks (Chapter 14 and Appendix A).

In the Enterprise area, its special mdbox storage format provides a storage system that scales well even for millions of accounts (Section 7.3) but also allows the use of slower hard drives (Section 7.3.4) or even object storage (Section 20.1).

It even allows active/active clusters to be implemented without great effort; with a little orientation you can create a stable and robust cluster system that you don’t need to handle with kid gloves (Section 16.4).

By the way, the Debian distribution measures which packages are installed and how often – and the long-term charts show a clear trend: While Courier and Cyrus are on the way down, Dovecot is shooting upwareds.

I hope you will have the same experience in this book: that your interest (which obviously exists) in Dovecot will turn to excitement as you go through the chapters.

A powerful IMAP server like Dovecot contains many details that you need to know and consider. The flexibility of the IMAP protocol itself, which does not even define the namespace for IMAP folders, means there are plenty of ways to influence things, but of course these can also go wrong.

In the first years, Dovecot was easy to learn even without a book. But in the face of its current complexity, simply reading through the (very well) commented configuration and example files is no longer enough. Many details have an effect in different areas, so you need to keep an eye on the whole system whenever you make an adjustment. I keep encountering systems where a minor bad decision was made that had catastrophic effects on the whole a few years later.

This book wants to take you by the hand and lead you through the various subjects relevant to your (future? current?) IMAP server. Because everything is connected, the book is sorted by subjects and organizational matters rather than the technical structure of the software. That means that details are spread across the chapters, as they are discussed where they have an effect.

Our chapters describe how to perform tasks and resolve problems. This book is in some ways a complete work of reference, though the speed at which Dovecot is being developed has ensured that new features were released at the time of going to press and could therefore not be included. It is not a technical reference; that is what the Dovecot Wiki[2] and the man pages of the various tools are for, and they will always be more up-to-date than a book.

Once you have understood the concept, structure and procedure of Dovecot with the help of this book, everything else will be easy and quick to understand, and smaller updates to the tools do not create any difficulties in comprehension. Nevertheless, you will find technical references in the appendix of this book; cross references will take you quickly to the relevant explanations in the book.

As with my Postfix book, there is a mailing list for Dovecot where readers and Dovecot admins discuss questions and help one another. The mailing list will also ensure that you are always aware of the latest developments. You can find the details and join the mailing list at http://www.dovecot-book.com. There you will find updates, corrections and other notes on the chapters of the book edition.

I also welcome feedback on the book, which you can send to <p.heinlein@heinlein-support.de>. Maybe we will even meet in person at a trade fair, conference or other event. Or you could drop in at our Berlin Linux Academy for a Postfix, Dovecot or other admin training course. And if you want to take advantage of our experience for a concrete project, my team and I will be happy to help on site: http://www.heinlein-support.de

My thanks go to the Heinlein Support team: after all, we have been running IMAP clusters for many years, which is where we tried and learned many of the things that are now found in this book as experience and best practice. All admins from Heinlein Hosting, colleagues from Heinlein Consulting and of course the good spirits in all the other areas have a direct or indirect share in this book. Thank you for that. I particularly want to thank Peer Hartleben, who has supported me at my company for 10 years and who co-authored the old IMAP book from which some text passages have been included in this book.

As in almost every book project, my children and wife were the ones who suffered most as the book turned into a fifth member of the family for 15 months, always there at the lunch table and stealing my free time. I hope it was worth it, and that you benefit from reading it.

So, have fun with your keyboard,

Peer Heinlein, February 2014

[1] “The book of IMAP – building a mail server with Courier and Cyrus”, Open Source Press/No Starch Press 2007.

[2] http://wiki2.dovecot.org

Chapter 1. Protocols and Terms

What is a mail server? People often imagine a machine in some data processing center that takes care of email administration. In fact, a mail server is modular, consisting of a variety of components and programs, and communicates using various protocols. The same is true for commercial solutions that provide this variety under one product name. In most cases, the various tasks involved can be distributed among multiple servers, which means “the mail server” is actually composed of multiple machines.

1.1. An Overview of Terms

Mail servers use the Simple Mail Transport Protocol (SMTP) to communicate with each other in order to deliver emails. Clients such as Outlook, KMail, Thunderbird, LiveMail oder Evolution usually deliver their e-mails via SMTP to the relay server responsible for them. However, SMTP is suitable only for sending emails, not for receiving them, so SMTP cannot be used to retrieve your inbox or create email directories in it. As a consequence, a Mail Transfer Agent (MTA) that transports emails received from clients or other servers to their destinations has nothing to do with reception mechanisms such as POP3, IMAP or similar. In short: this book will describe SMTP servers such as Postfix, QMail, Exim or Sendmail only where Dovecot and the MTA come into contact. We will analyze the best way to receive and route Dovecot domains, and how to map the user list and the quota settings. Advanced knowledge of MTA, and the whole area of spam and antivirus software, are part of this subject and have already been extensively documented.

Post Office Protocol Version 3 (POP3) is a comparatively simple protocol with few configuration options, so pure POP3 servers require very little administration.

The Internet Message Access Protocol (IMAP), the big brother of POP3, is quite complex. This book will focus mainly on the numerous ways to influence the email retrieval process and and to administrate emails. When you have finished reading it, you will be able to implement challenging scenarios. Well-known IMAP servers always provide a POP3 daemon as well; for programmers dealing with the complexity of the IMAP protocol, there is no difficulty in offering the POP3 protocol as an addition from the same data base.

This book is all about Dovecot, the most powerful and modern open-source IMAP server. As Dovecot also contains a POP3 server, this book will often be referring to both services, even if we use the term IMAP server for the purpose of convenience. To be precise, Dovecot is a POP3, IMAP, LMTP, Managesieve, SASL and Postfix-Policy-Daemon server – with an SMTP server planned as well. That makes Dovecot a real all-rounder, as we will see again and again throughout this book.

LMTP, the Local Message Transfer Protocol, is closely related to SMTP, but is designed only for local use, such as transferring emails from one Mail Transfer Agent (such as Postfix) to other email components, specifically the Mail Delivery Agent (MDA). In this case it has an advantage over SMTP in that it is easier to determine the email addresses where local delivery was possible, and the email addresses where it wasn’t. Unlike SMTP, after the DATA command LMTP outputs an individual status message for each recipient stating whose inbox the email was actually saved in. SMTP, by contrast, can only return one single status message at this point. If an email cannot be saved successfully in an inbox, the email must be rejected by the server for all recipients.

LMTP should be used only locally within a network, for example for delivery from an SMTP front relay (e. g. Postfix) to the actual email backend (Dovecot, Cyrus, Exchange) that is responsible for saving the email.

Groupware is software that manages tasks, calendars, email contacts and address books for multiple users. Some versions also include resource and room management, file management and other areas. Strictly speaking, Groupware is not really related to emails, but such software solutions usually contain their own email service, or just a webmailer that uses an IMAP server that is already running.

1.2. What makes IMAP so complex?

The POP3 server waits until a user has logged in successfully, and then transmits the unread messages saved in the user’s inbox. Depending on the client request, transmitted messages are then either deleted to save space or marked as read and kept. This is not particularly challenging, so software cannot really go wrong here.

An IMAP server is rather different: instead of just delivering emails to users, it organizes all of the email administration. The user’s mail client works as a type of “remote” for the inbox kept on the server.

An IMAP server makes the memory available and stores all emails, so it may be appropriate to set up quotas to force users to clear up from time to time and free up valuable memory. When a user creates a folder to sort his emails, the IMAP server has to map this folder structure and sort the emails accordingly. It is possible to search for senders or text blocks on the server, and IMAP also allows users to flag emails as read, unread or answered, and even create their own key words to flag emails. Shared folders accessed by several email users in parallel are another useful function.

An IMAP server allows users to maintain their inbox from multiple different computers; wherever they access their emails, they will find exactly the same data, rendering synchronization unnecessary.

All this is highly challenging for the IMAP protocol and therefore the programmers. For administrators, the effort required to configure IMAP servers is limited as soon as they have been connected to a user database. However, they offer plenty of decisions that can take you down a good or bad path.

Operating IMAP servers involves plenty of traps and technical difficulties that this book will describe in detail:

Performance

As user numbers increase, the load on the IMAP server becomes apparent. It has to manage millions or billions of emails, operate thousands or hundreds of thousands of IMAP connections in parallel, and deal with search operations in emails or extensive copying. Depending on the scenario, consumption of file handles by IMAP servers can be very heavy and create a high I/O load on the data carriers.

Availability

Today, email must be available around the clock as any failure can be damaging to business. Even with a robust IMAP server, any infrastructure above a certain size should ensure high availability in some form or another.

Storage

An email storage can grow to a considerable size. Even though it is easy today to implement multiple TByte hard disks in 1HE servers, IMAP servers require other storage concepts at ISP level, such as NAS, SAN or even object storage such as Ceph/Rados, Scality or S3.

Quotas

Here, again, some points should be considered during implementation so the server can be operated smoothly and requires no support.

Legal situation

Emails are subject to the sanctity of the mail; not many people know that negligent mistakes by the administrator may be sanctioned under criminal law. However, this is a general problem with mail servers, so this book will not discuss the problem in more detail.

Raise the curtain, clear the stage, and let’s finally start installing and configuring Dovecot!

Part I. Dovecot for all purposes

Chapter 2. Installation

A variety of sources provide ready-made installation packages for Dovecot, including “daily builds” that allow you to install the latest version. I would advise you not to compile Dovecot yourself unless you want to create unnecessary work for yourself.

For a long time, Dovecot version branch 1.x ruled the world – Debian and Ubuntu distributions as well as older versions of Enterprise (SLES/RHEL) sometimes still contain versions from this series. But you won’t want to install this branch any more, because versions from 2.0 onwards contain many relevant improvements that you do not want to do without.

At the time of going to press, the current version branches are 2.1.x and 2.2.x. They do not differ greatly from one another, so you can choose either. What is particularly interesting about the 2.2 branch is the overhauled dsync replication, which allows active/active clusters to be set up with real-time replication. Choose 2.2.x if you can. If your distribution only offers 2.1.x, you’d rather not fall back on third-party sources and have no special cluster requirements, 2.1 will do fine, and you can easily upgrade later.

However, for larger set-ups you should use a version from 2.0.16, where Dovecot author Timo Sirainen included the important auto: feature (see Section 7.5).

2.1. Installation under Debian/Ubuntu

If you want the latest versions, you should fall back on the backports platform.[3]

To integrate backports, you add the backport sources to /etc/apt/sources.list:

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!