Email with Postfix, Dovecot and MySQL on Debian 6 (Squeeze …

by Lanh on July 30, 2014

Updated Friday, July 1st, 2011 by Linode

The Postfix Mail Transfer Agent (MTA) is a high performance open source e-mail server system. This guide will help you get Postfix running on your Debian 6 (Squeeze) Linode, using Dovecot for IMAP/POP3 service and MySQL to store information on virtual domains and users. This guide is largely based on Christoph Haas’s great ISP-style Email Server with Debian-Lenny and Postfix 2.5 guide and HowtoForge Groupware Server With Group-Office, Postfix, Dovecot And SpamAssassin On Debian Lenny (5.0), with some packages omitted.

It is assumed that you have followed the steps outlined in our getting started guide. All configuration will be performed in a terminal session; make sure you’re logged into your Linode as root via SSH.

NOTE: Please read all of the information presented in this guide carefully. There are many files and commands that will need to be edited as part of the setup process: please do not simply copy and paste the example blocks.

Set the Hostname

Before you begin installing and configuring the components described in this guide, please make sure you’ve followed our instructions for setting your hostname. Issue the following commands to make sure it is set properly:

The first command should show your short hostname, and the second should show your fully qualified domain name (FQDN).

Install Required Packages

Issue the following commands to install any outstanding package updates:

1
2apt-get update
apt-get upgrade

Issue the following command to get the required packages installed on your VPS:

1apt-get install postfix postfix-mysql postfix-doc mysql-client mysql-server dovecot-common dovecot-imapd dovecot-pop3d libsasl2-2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql openssl telnet mailutils

This will install the Postfix mail server, the MySQL database server, the Dovecot IMAP and POP daemons, and several supporting packages that provide services related to authentication. You will be prompted to choose a root password for MySQL; make sure you select a strong password comprised of letters, numbers, and non-alphanumeric characters. Write this password down and keep it in a safe place for later reference.

Next, you’ll be prompted to select the type of mail server configuration you want for your VPS. Select “Internet Site” and continue.

Now you’ll need to set the system mail name. This should be a fully qualified domain name (FQDN) that points to your Linode’s IP address. This example uses an example organization’s domain. You should set the reverse DNS for your Linode’s IP address to the fully qualified domain name you assign as the system mail name, while other domains you wish to host email for will be handled later through virtual domain setup steps.

This completes the initial package configuration steps. Next, you’ll set up a MySQL database to handle virtual domains and users.

Set up MySQL for Virtual Domains and Users

Start the MySQL shell by issuing the following command. You’ll be prompted to enter the root password for MySQL that you assigned during the initial setup.

You’ll be presented with an interface similar to the following.

1
2
3
4
5
6
7
8
9
10
11Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 40
Server version: 5.1.49-3 (Debian)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type ‘help;’ or ‘h’ for help. Type ‘c’ to clear the current input statement.

mysql>

Issue the following command to create a database for your mail server and switch to it in the shell:

1
2CREATE DATABASE mail;
USE mail;

Create a mail administration user called mail_admin and grant it permissions on the mail database with the following commands. Please be sure to replace “mail_admin_password” with a password you select for this user.

1
2
3GRANT SELECT, INSERT, UPDATE, DELETE ON mail.* TO ‘mail_admin’@'localhost’ IDENTIFIED BY ‘mail_admin_password’;
GRANT SELECT, INSERT, UPDATE, DELETE ON mail.* TO ‘mail_admin’@'localhost.localdomain’ IDENTIFIED BY ‘mail_admin_password’;
FLUSH PRIVILEGES;

Create the virtual domains table with the following command:

1CREATE TABLE domains (domain varchar(50) NOT NULL, PRIMARY KEY (domain) );

Create a table to handle mail forwarding with the following command:

1CREATE TABLE forwardings (source varchar(80) NOT NULL, destination TEXT NOT NULL, PRIMARY KEY (source) );

Create the users table with the following command:

1CREATE TABLE users (email varchar(80) NOT NULL, password varchar(20) NOT NULL, PRIMARY KEY (email) );

Create a transports table with the following command:

1CREATE TABLE transport ( domain varchar(128) NOT NULL default ”, transport varchar(128) NOT NULL default ”, UNIQUE KEY domain (domain) );

Exit the MySQL shell by issuing the following command:

Check that MySQL is set up to bind to localhost (127.0.0.1) by looking at the file /etc/mysql/my.cnf. You should have the following line in the configuration file:

/etc/mysql/my.cnf

bind-address = 127.0.0.1

This is required for Postfix to be able to communicate with the database server. If you have MySQL set up to run on another IP address (such as an internal IP), you will need to substitute this IP address in place of 127.0.0.1 during the Postfix configuration steps. Please note that it is not advisable to run MySQL on a publicly-accessible IP address.

If you changed MySQL’s configuration, restart the database server with the following command:

Next, you’ll perform additional Postfix configuration to set up communication with the database.

Configure Postfix to work with MySQL

Create a virtual domain configuration file for Postfix called /etc/postfix/mysql-virtual_domains.cf with the following contents. Be sure to replace “mail_admin_password” with the password you chose earlier for the MySQL mail administrator user.

/etc/postfix/mysql-virtual_domains.cf

user = mail_admin password = mail_admin_password dbname = mail query = SELECT domain AS virtual FROM domains WHERE domain=’%s’ hosts = 127.0.0.1

Create a virtual forwarding file for Postfix called /etc/postfix/mysql-virtual_forwardings.cf with the following contents. Be sure to replace “mail_admin_password” with the password you chose earlier for the MySQL mail administrator user.

/etc/postfix/mysql-virtual_forwardings.cf

user = mail_admin password = mail_admin_password dbname = mail query = SELECT destination FROM forwardings WHERE source=’%s’ hosts = 127.0.0.1

Create a virtual mailbox configuration file for Postfix called /etc/postfix/mysql-virtual_mailboxes.cf with the following contents. Be sure to replace “mail_admin_password” with the password you chose earlier for the MySQL mail administrator user.

/etc/postfix/mysql-virtual_mailboxes.cf

user = mail_admin password = mail_admin_password dbname = mail query = SELECT CONCAT(SUBSTRING_INDEX(email,,-1),’/’,SUBSTRING_INDEX(email,,1),’/’) FROM users WHERE email=’%s’ hosts = 127.0.0.1

Create a virtual email mapping file for Postfix called /etc/postfix/mysql-virtual_email2email.cf with the following contents. Be sure to replace “mail_admin_password” with the password you chose earlier for the MySQL mail administrator user.

/etc/postfix/mysql-virtual_email2email.cf

user = mail_admin password = mail_admin_password dbname = mail query = SELECT email FROM users WHERE email=’%s’ hosts = 127.0.0.1

Set proper permissions and ownership for these configuration files by issuing the following commands:

1
2chmod o= /etc/postfix/mysql-virtual_*.cf
chgrp postfix /etc/postfix/mysql-virtual_*.cf

Next, create a user and group for mail handling. All virtual mailboxes will be stored under this user’s home directory.

1
2groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /home/vmail -m

Issue the following commands to complete the remaining steps required for Postfix configuration. Please be sure to replace “server.example.com” with the fully qualified domain name you used for your system mail name.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23postconf -e ‘myhostname = server.example.com’
postconf -e ‘mydestination = server.example.com, localhost, localhost.localdomain’
postconf -e ‘mynetworks = 127.0.0.0/8′
postconf -e ‘message_size_limit = 30720000′
postconf -e ‘virtual_alias_domains =’
postconf -e ‘virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf’
postconf -e ‘virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf’
postconf -e ‘virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf’
postconf -e ‘virtual_mailbox_base = /home/vmail’
postconf -e ‘virtual_uid_maps = static:5000′
postconf -e ‘virtual_gid_maps = static:5000′
postconf -e ‘smtpd_sasl_auth_enable = yes’
postconf -e ‘broken_sasl_auth_clients = yes’
postconf -e ‘smtpd_sasl_authenticated_header = yes’
postconf -e ‘smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination’
postconf -e ‘smtpd_use_tls = yes’
postconf -e ‘smtpd_tls_cert_file = /etc/postfix/smtpd.cert’
postconf -e ‘smtpd_tls_key_file = /etc/postfix/smtpd.key’
postconf -e ‘virtual_create_maildirsize = yes’
postconf -e ‘virtual_maildir_extended = yes’
postconf -e ‘proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps’
postconf -e virtual_transport=dovecot
postconf -e dovecot_destination_recipient_limit=1

This completes the configuration for Postfix. Next, you’ll make an SSL certificate for the Postfix server that contains values appropriate for your organization.

Create an SSL Certificate for Postfix

Issue the following commands to create the SSL certificate (the openssl command spans two lines, but should be entered as a single command):

1
2cd /etc/postfix
openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048 -nodes -keyout smtpd.key -keyform PEM -days 365 -x509

You will be asked to enter several values similar to the output shown below. Be sure to enter the fully qualified domain name you used for the system mailname in place of “server.example.com”.

1
2
3
4
5
6
7Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New Jersey
Locality Name (eg, city) []:Absecon
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany, LLC
Organizational Unit Name (eg, section) []:Email Services
Common Name (eg, YOUR name) []:server.example.com
Email Address []:support@example.com

Set proper permissions for the key file by issuing the following command:

1chmod o= /etc/postfix/smtpd.key

This completes SSL certificate creation for Postfix. Next, you’ll configure saslauthd to use MySQL for user authentication.

Configure saslauthd to use MySQL

Issue the following command to create a directory for saslauthd:

1mkdir -p /var/spool/postfix/var/run/saslauthd

Make a backup copy of the /etc/default/saslauthd file by issuing the following command.

1cp -a /etc/default/saslauthd /etc/default/saslauthd.bak

Edit the file /etc/default/saslauthd to match the configuration shown below.

/etc/default/saslauthd

START=yes DESC=”SASL Authentication Daemon” NAME=”saslauthd” MECHANISMS=”pam” MECH_OPTIONS=”” THREADS=5 OPTIONS=”-c -m /var/spool/postfix/var/run/saslauthd -r”

Next, create the file /etc/pam.d/smtp and copy in the following two lines. Be sure to change “mail_admin_password” to the password you chose for your mail administration MySQL user earlier.

/etc/pam.d/smtp

auth required pam_mysql.so user=mail_admin passwd=mail_admin_password host=127.0.0.1 db=mail table=users usercolumn=email passwdcolumn=password crypt=1 account sufficient pam_mysql.so user=mail_admin passwd=mail_admin_password host=127.0.0.1 db=mail table=users usercolumn=email passwdcolumn=password crypt=1

Create a file named /etc/postfix/sasl/smtpd.conf with the following contents. Be sure to change “mail_admin_password” to the password you chose for your mail administration MySQL user earlier.

/etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd mech_list: plain login allow_plaintext: true auxprop_plugin: mysql sql_hostnames: 127.0.0.1 sql_user: mail_admin sql_passwd: mail_admin_password sql_database: mail sql_select: select password from users where email = ‘%u’

Set proper permissions and ownership for these configuration files by issuing the following commands:

1
2chmod o= /etc/pam.d/smtp
chmod o= /etc/postfix/sasl/smtpd.conf

Add the Postfix user to the sasl group and restart Postfix and saslauthd by issuing the following commands:

1
2
3adduser postfix sasl
service postfix restart
service saslauthd restart

This completes configuration for saslauthd. Next, you’ll configure Dovecot to use MySQL for IMAP/POP3 user authentication.

Configure Dovecot

Edit the file /etc/postfix/master.cf and add the dovecot service to the bottom of the file.

/etc/postfix/master.cf

dovecot unix – n n – - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
Issue the following command to make a backup copy of your /etc/dovecot/dovecot.conf file.

1cp -a /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.bak

Replace the contents of the file with the following example, substituting your system’s domain name for example.com.

/etc/dovecot/dovecot.conf

protocols = imap imaps pop3 pop3s log_timestamp = “%Y-%m-%d %H:%M:%S “ mail_location = maildir:/home/vmail/%d/%n/Maildir

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

namespace private {
separator = . prefix = INBOX. inbox = yes
}

protocol lda {
log_path = /home/vmail/dovecot-deliver.log auth_socket_path = /var/run/dovecot/auth-master postmaster_address = postmaster@example.com mail_plugins = sieve global_script_path = /home/vmail/globalsieverc
}

protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}

auth default {
user = root

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

userdb static {
args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes
}

socket listen {

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

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

}

}

MySQL will be used to store password information, so /etc/dovecot/dovecot-sql.conf must be edited. Issue the following command to make a backup copy of the existing file.

1cp -a /etc/dovecot/dovecot-sql.conf /etc/dovecot/dovecot-sql.conf.bak

Replace the contents of the file with the following example, making sure to replace “main_admin_password” with your mail password.

/etc/dovecot/dovecot-sql.conf

driver = mysql connect = host=127.0.0.1 dbname=mail user=mail_admin password=mail_admin_password default_pass_scheme = CRYPT password_query = SELECT email as user, password FROM users WHERE email=’%u’;

Dovecot has now been configured. You must restart it to make sure it is working properly:

Now check your /var/log/mail.log to make sure dovecot started without errors. Your log should have lines similar to the following:

/var/log/mail.log

Jun 13 17:01:58 li263-140 dovecot: Dovecot v1.2.15 starting up (core dumps disabled) Jun 13 17:01:58 li263-140 dovecot: auth-worker(default): mysql: Connected to 127.0.0.1 (mail)

Before testing dovecot, you must change the permissions on /etc/dovecot/dovecot.conf to allow the vmail user to access them:

1
2chgrp vmail /etc/dovecot/dovecot.conf
chmod g+r /etc/dovecot/dovecot.conf

You can test your POP3 server to make sure it’s running properly by issuing the following command.

You should see output similar to the following in your terminal:

1
2
3
4Trying 127.0.0.1…
Connected to localhost.localdomain.
Escape character is ‘^]’.
+OK Dovecot ready.

Enter the command “quit” to return to your shell. This completes the Dovecot configuration. Next, you’ll make sure aliases are configured properly.

Configure Mail Aliases

Edit the file /etc/aliases, making sure the “postmaster” and “root” directives are set properly for your organization.

/etc/aliases

postmaster: root root: postmaster@example.com

After modifying this file, you must run the following commands to update aliases and restart Postfix:

1
2newaliases
service postfix restart

This completes alias configuration. Next, you’ll test Postfix to make sure it’s operating properly.

Testing Postfix

To test Postfix for SMTP-AUTH and TLS, issue the following command:

While connected to Postfix, issue the following command:

You should see output similar to the following, with the line “250-STARTTLS” included:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16Trying 127.0.0.1…
Connected to localhost.localdomain.
Escape character is ‘^]’.
220 plato.example.com ESMTP Postfix (Debian/GNU)
ehlo localhost
250-plato.example.com
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Issue the command quit to terminate the Postfix connection. Next, you’ll populate the MySQL database with domains and email users.

Setting up Domains and Users

Please note that you’ll need to modify the DNS records for any domains that you wish to handle email by adding an MX record that points to your mail server’s fully qualified domain name. If MX records already exist for a domain you would like to handle the email for, you’ll need to either delete them or set them to a larger priority number than your mail server. Smaller priority numbers indicate higher priority for mail delivery, with “0” being the highest priority.

We’ll use the MySQL shell to add support for the domain “example.com”, which will have an email account called “sales”. You should substitute one of your domains for “example.com” in these statements, along with a strong password for the “password” entry in the second SQL statement.

1
2
3
4
5
6mysql -u root -p

USE mail;
INSERT INTO domains (domain) VALUES (‘example.com’);
INSERT INTO users (email, password) VALUES (‘sales@example.com’, ENCRYPT(‘password’));
quit

You’ll need to send a welcome message to new email accounts before they can be accessed via IMAP or POP3. This is because the mailboxes for new users won’t be created until an email is received for them. To send a welcome message from the command line, you may use the mailx utility. Issue the following command to send the message.

Press Ctrl+D to complete the message. You can safely leave the field for “CC:” blank. This completes the configuration for a new domain and email user.

Given the possibility for virtual hosting a large number of virtual domains on a single mail system, the username portion of an email address (i.e. before the @ sign) is not sufficient to authenticate to the mail server. When email users authenticate to the server, they must supply their email clients with the entire email address created above as their username.

Check Your Logs

After you have sent the test mail, you’ll want to check your error logs to make sure the mail was delivered. First check your mail.log located in /var/log/mail.log. You should see something similar to the following:

/var/log/mail.log

Jun 13 17:05:40 li263-140 postfix/cleanup[5435]: E7AA723FD2: message-id=> Jun 13 17:05:40 li263-140 postfix/qmgr[5349]: E7AA723FD2: from=< >, size=376, nrcpt=1 (queue active) Jun 13 17:05:41 li263-140 postfix/pipe[5439]: E7AA723FD2: to=< >, relay=dovecot, delay=0.24, delays=0.08/0.01/0/0.15, dsn=2.0.0, status=sent (delivered via dovecot service) Jun 13 17:05:41 li263-140 postfix/qmgr[5349]: E7AA723FD2: removed

Next you should check the Dovecot delivery log located in /home/vmail/dovecot-deliver.log. The contents should look similar to the following:

/home/vmail/dovecot-deliver.log

2011-06-13 17:05:41 deliver(sales@example.com): Info: msgid=>: saved mail to INBOX

Now you can test to see what the users of your email server would see with their email clients.

Test the Mailbox

To test the sales@example.com mail box, navigate to the mailbox directory /home/vmail/example.com/sales/Maildir and type the following command:

You should see output similar to the following:

1
2
3
4
5
6
7
8
9.
./dovecot.index.log
./dovecot-uidvalidity
./cur
./tmp
./dovecot-uidvalidity.4df67ba5
./new
./new/1307999141.M4912P5440.plato,S=452,W=464
./dovecot-uidlist

Now you can test using a mail client. When configuring your local email client, use the full email address for the mailbox you wish to connect to as the username. You may use mutt for this test. It is not installed by default so you may need to install it (apt-get install mutt). Type the following command to view user’s mail:

You may be prompted to create the root mailbox. This is not required. If you see an e-mail in the inbox, you’ve successfully configured Postfix, Dovecot, and MySQL to provide email services for virtual domains and users on your Linode. Please consult the “More Information” section for additional resources that may prove useful in the administration of your new email server.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

More here: Email with Postfix, Dovecot and MySQL on Debian 6 (Squeeze …

Breakfast recipes Android

Troubleshooting Problems with Postfix, Dovecot, and MySQL – Linode

by Lanh on July 30, 2014

Updated Monday, July 22nd, 2013 by Linode

This guide is a companion to the Postfix, Dovecot, and MySQL installation guide. Because setting up a mail server is tricky, we’ve created this companion troubleshooting guide to help you work through and resolve any problems you might be experiencing. By the time you reach the end of this guide, you’ll know how to debug problems with your Postfix, Dovecot, and MySQL mail server.

The first section, Troubleshooting Checklist_, has a top-down approach to troubleshooting that will help you find specific errors for your mail server. The second section, Step-by-Step Configuration_, uses a bottom-up approach that shows you how to get a basic mail server functioning and then gradually add more features.

Troubleshooting Checklist

Correctly diagnosing a problem is the first step in solving it. At first glance, many mail server errors can seem quite general. Usually the first sign of a problem is that you try to create a test mail account and can’t connect. This section is a crash course in finding mail server errors. We recommend reading through the following sections in order, because they progress from general to more specific troubleshooting techniques.

Are Postfix and Dovecot Running?

Sometimes your mail server is not fuctioning correctly because the needed services are not running. For a mail server that has been running for a long time, resource overuse is the most likely cause of stopped services. It doesn’t hurt to check your resource use to rule out that problem. However, when you’re just setting up a new mail server, it’s more likely that your service startup problems are being caused by configuration errors. Some configuration errors – particularly syntax errors – are serious enough that they can prevent a service from starting.

To check that Postfix and Dovecot are running and to find startup errors, follow these steps:

Run this command to check that Postfix is running:

You should see the following output:

Next, run this command to check that Dovecot is running:

You should see output similar to the following:

1dovecot start/running, process 2241

Examine the results. If you see no output, or output that says stop/waiting or not running, the service is not running. The next step is to try restarting the services.

Try to restart the services. Restarting Postfix and Dovecot is also a good troubleshooting procedure even if they’re currently running, because then you can examine the startup messages, which can give you troubleshooting clues. Enter the following command to restart Postfix:

You should see the following messages:

1
2* Stopping Postfix Mail Transport Agent postfix [ OK ]
* Starting Postfix Mail Transport Agent postfix [ OK ]

Execute the following command to restart Dovecot:

You should see the following messages:

1
2dovecot stop/waiting
dovecot start/running, process 31171

Examine the results. If you get an error, or the restart message for Dovecot doesn’t include a new process ID, there’s something preventing the service from starting.
If you received a specific error from the restart attempt, search for it online.

Check the applications’ startup logs to see more detailed messages. Postfix’s stop and start messages are logged in var/log/mail.log (along with all its other messages). Enter the following command to view the most recent lines in the log:

On a normal restart, you should see the following:

/var/log/mail.log

1
2May 22 15:41:59 godel postfix/master[19624]: terminating on signal 15
May 22 15:41:59 godel postfix/master[20232]: daemon started — version 2.9.6, configuration /etc/postfix

Dovecot’s default startup log is also in /var/log/mail.log. On a normal restart, you should see the following:

/var/log/mail.log

1
2May 22 17:46:54 master: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
May 22 17:48:09 master: Info: Dovecot v2.0.19 starting up (core dumps disabled)

If you moved the Dovecot logs, the normal Dovecot startup messages will be in /var/log/dovecot.log instead. If you can’t find the Dovecot logs, locate them with the following command:

If you don’t see these normal startup messages, check for errors instead. Search for errors online.

If there’s a problem during Dovecot’s startup, you should also check /var/log/upstart/dovecot.log. On a normal startup, nothing will be logged to this file. However, if there is a startup problem, an entry will be added in this log which can be quite helpful. To view this file, run the following command:

1tail /var/log/upstart/dovecot.log

Here’s an example where a syntax error in the /etc/dovecot/conf.d/10-master.conf file has been identified:

/var/log/upstart/dovecot.log

1doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-master.conf line 36: Unexpected ‘}’

If you find a syntax error, open up the offending file and look at the line mentioned (Line 36 in the example above). It’s actually fairly common to get syntax errors during the Dovecot setup process, because there are so many different files and a lot of nested brackets.
Use Notepad++ or some other program that can easily match brackets to help you fix the error. Or, you could restore the appropriate default configuration file (named with .orig, if you were following the main setup guide).
Checking the Logs

If Postfix, Dovecot, and MySQL are running, the next troubleshooting step is to check the mail logs. By default, all of the incoming and outgoing connections and any associated errors get logged in /var/log/mail.log. One of the most helpful ways to view the log file is with the tail command, which when combined with the -f flag, shows you the most recent part of the log live as it’s updated.

Start tailing the log by entering the following command:

1tail -f /var/log/mail.log

Send yourself a test message or make a connection to the mail server.
View the log as it updates with the relevant information.
To stop tailing, press CTRL-C.
If you see an error or warning in the log, copy it. Search for that exact error online (without the details specific to your server), and you’ll likely be able to find a solution or additional troubleshooting help.

Enabling Verbose Logs

The default mail log may not contain all the information you need. In that case, the next step is to enable verbose logging for Postfix and Dovecot, and to separate the Postfix and Dovecot logs into two separate files so they’re easier to sort through. The Postfix log will document messages that are relayed to or from outside servers, and the Dovecot log will record authorization attempts.

Dovecot

Follow these instructions to enable verbose logging for Dovecot and change the log location to /var/log/dovecot.log:

Open the /etc/dovecot/conf.d/10-logging.conf file for editing by entering the following command:

1nano /etc/dovecot/conf.d/10-logging.conf

Add this line to set the new file path for the log:

/etc/dovecot/conf.d/10-logging.conf

1log_path = /var/log/dovecot.log

Uncomment the auth_verbose and mail_debug lines, and then set them to yes:

/etc/dovecot/conf.d/10-logging.conf

1
2
3auth_verbose = yes

mail_debug = yes

Save your changes.

Restart Dovecot by entering the following command:

The Dovecot log will now display more information about authorization attempts and inbox connections. You can view the new log at /var/log/dovecot.log. Remember to disable verbose logging when you’re done troubleshooting so your server doesn’t fill up with logs.

Postfix

Follow these instructions to enable verbose logging for Postfix:

Open the /etc/postfix/master.cf files for editing by entering the following command:

1nano /etc/postfix/master.cf

Add a -v to the smtp line to enable verbose logging:

/etc/postfix/master.cf

1
2
3
4
5# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n – – – – smtpd -v

Save your changes.

Restart Postfix by entering the following command:

The Postfix log will now display more information about messages that are coming from or going to outside servers. You can still view the log at /var/log/mail.log. Remember to disable verbose logging when you’re done troubleshooting so your server doesn’t fill up with logs.

Checking Port Availability

Sometimes email problems occur because the mail server and mail client aren’t talking to each other on the same ports. For mail to get from client to server, or vice versa, both have to be using the same ports, and those ports also have to be open along the internet route between the two. If you are following the accompanying Postfix, Dovecot, and MySQL installation guide, you should be using the following ports:

25, 465, or 587 with TLS encryption for outgoing mail (SMTP)
993 with SSL encryption for incoming IMAP
995 with SSL encryption for incoming POP3
First, check your mail client settings and make sure that you have the correct ports and security settings selected.

Next, use the Telnet tool to check that ports are open both on your Linode and on the route between your client and your Linode. The same test should be run on both your Linode and your home computer. First we’ll present how to run the test from both locations, and then we’ll discuss the implications.

Checking from a Linode

To test on your Linode, follow these steps:

Establish an SSH connection to your Linode.

Run the following command, replacing 12.34.56.78 with your Linode’s IP address:

Exit Telnet by pressing CTRL-], then enter quit.
Repeat Step 2 for ports 465, 587, 993, and 995.
Read the discussion of Telnet outcomes below, and use the output shown at the end of this section to analyze your results.

Checking from a Mac

To run a Telnet test on a Mac, follow these steps:

Open the Terminal application.

Run the following command, replacing 12.34.56.78 with your Linode’s IP address:

Exit Telnet by pressing CTRL-], then enter quit.
Repeat Step 2 for ports 465, 587, 993, and 995.
Read the discussion of Telnet outcomes below, and use the output shown at the end of this section to analyze your results.

Checking from a PC

To run a Telnet test on a Windows computer, follow these steps. You will need to start by installing Telnet, since it doesn’t come with Windows by default:

Open the Control Panel.
Select Programs.
From Programs and Features, select Turn Windows features on or off.
Select Telnet Client from the menu.
Click OK.
Wait while the changes are applied.
Open the command prompt.

Run the following command, replacing 12.34.56.78 with your Linode’s IP address:

Exit Telnet by pressing CTRL-], then enter quit.
Repeat Step 8 for ports 465, 587, 993, and 995.
Read the discussion of Telnet outcomes below, and analyze your results according to the output shown below.

Analyzing the Results

If the test is successful, you should see output similar to the following:

1
2
3
4Trying 12.34.56.78…
Connected to li468-222.members.linode.com.
Escape character is ‘^]’.
220 host.example.com ESMTP Postfix (Ubuntu)

To cancel the connection, press CTRL-], then enter quit. If the test fails, you will see a Connection refused message and Telnet will quit on its own.

If you run the test on your Linode and it fails, you should check that you’ve configured the ports properly in your mail server setup (see Steps 33-34 in the Dovecot section of the setup guide), that you’ve enabled ports 465 and 587 (see Steps 26-30 in the Postfix section of the setup guide), and that you don’t have any Firewall rules in place that block them.

If you run the test on your Linode and it succeeds, but the test from your home computer fails, that indicates that the ports are being blocked somewhere on the network between your home computer and your Linode. It could be at your router, your ISP (Internet Service Provider), someone else’s ISP, etc. The best way to diagnose networking issues is to generate an MTR report.

If the Telnet tests on your Linode and your home computer both succeed, and your mail client settings are correct, you can probably rule out any problems with ports.

Verifying Your Login Credentials

Next we’ll focus on your login credentials. If they aren’t configured properly, this can cause problems:

Username and password are not accepted in your mail client
Prompted for your password over and over again
Unable to connect to the mail server
The first and easiest step is re-entering your username and password in your mail client. Make sure you use the full username, including the @example.com part. Usernames and passwords are case-sensitive. If you’re sure that you’ve entered the information correctly in your mail client, authorization may not be configured properly on the server side.

The next thing to check is that your username and password are entered properly in the correct MySQL table. You can run the MySQL tests from the main setup article to make sure your tables are set up appropriately. You can also delete and re-add the appropriate row from the mailserver.virtual_users table to make sure the password was entered correctly. If the information is correct in the MySQL table, it may be that Dovecot is not configured to look up authorization credentials in the right location.

Dovecot includes an administrative tool which is very helpful in troubleshooting issues with login credentials. The doveadm user command lets you see the user database result for the username, user ID, group ID, and mailbox location for each email user. Reading the output from this tool tells you the database where Dovecot is looking for authorized users. If Dovecot is not looking for the expected database, you’ll need to change the authorization-related settings in Dovecot so that it is using MySQL to look up users, and not some other user database.

Run the doveadm command to look up your email user (including the @example.com part):

1doveadm user email1@example.com

If everything is working correctly, you should see output like this:

1
2
3
4userdb: email1@example.com
uid : 5000
gid : 5000
home : /var/mail/vhosts/example.com/email1

If instead you get:

1userdb lookup: user email1@example.com doesn’t exist

This could indicate that 1) You didn’t enter the email address correctly in the MySQL table – but we just checked that, so it could also be that 2) Dovecot is not looking for your user database in the right place.

If Dovecot can’t find the users in MySQL, it may still be looking for system users rather than virtual users. See if you get a response for your own SSH user:

Dovecot should not find output for your system user. If it does, it will look like this:

1
2
3
4
5userdb: myuser
system_groups_user: myuser
uid : 1000
gid : 1000
home : /home/myuser

If you do get this type of output, you need to adjust your Dovecot settings related to virtual users. If you don’t get output for the system users either, this still indicates that you have some kind of error in the Dovecot settings related to users. Go back to the Dovecot section of the main setup guide and pay special attention to the sections having to do with virtual users and the MySQL settings.

Step-by-Step Configuration

For some troubleshooting scenarios, you may find that a top-down approach doesn’t help you find the root cause of the problem. Sometimes, what you need is a bottom-up approach.

The bottom-up approach presented here breaks up the complex task of building a mail server into smaller chunks. This has two benefits. First, each section focuses on just a few mail server functions and includes fewer details, which makes it easier to understand. By the end of the project, you should have a deep understanding of how the mail server works. Second, each chunk adds a discrete amount of testable functionality to the mail server. This makes it easier to find errors by limiting the scope of their possible locations. For example, if your mail server was working after you completed “Basic Dovecot,” but is failing its tests after “Virtual Domains and Users,” you know that the error is related to something you did in that section.

The second part of this guide presents a step-by-step mail server build organized by function, progressing from core functions to more peripheral ones, with tests at each step. You should have the main setup guide open at the same time, because we will be referring back to it. As you read the main setup guide, you’ll notice that we are installing items in a different order here. The main guide is designed for a streamlined approach that avoids editing the same file multiple times. This guide is focused on a deeper understanding of each component, so you will sometimes need to jump around to different sections of the main guide for reference. Once you successfully complete a stage, I suggest that you make a system-level backup so you can get back to that point easily!

Keep in mind that the earlier builds presented here are functional, but should not be considered production-ready for security and functionality reasons, mainly because passwords are sent in plain text, and/or outgoing SMTP is not enabled.

Throughout this section, we will provide links to the appropriate Postfix and Dovecot documentation. These are great jumping-off points.

Setting Up

Read the Getting Started section of the main guide. Follow the steps outlined in that section before installing your mail server.

You may also want to log into your server as the root user, so you don’t have to type “sudo” for each command. You can log in as root by entering the following command:

Basic Postfix

In this section, you’ll install Postfix and configure it to deliver mail for your system user at your domain, which is the most basic configuration. You’ll also send a test message and view it using Mailutils.

Install Postfix by entering the following command:

When prompted, select Internet Site for the configuration. (See Steps 6 & 7 from the Installing Packages section of the primary guide, for this step and the next.)
Enter your fully-qualified domain name or any domain name that resolves to the server.

Open /etc/postfix/main.cf for editing, and add your domain(s) to the mydestination line. If your hostname and hosts files were set up correctly before installing Postfix, this list should already include your full-qualified domain name and several references to localhost, which you can leave as they are.

/etc/postfix/main.cf

1mydestination = example.com, localhost

Restart Postfix by entering the following command:

Use that command whenever the instructions tell you to restart Postfix. Substitute dovecot for postfix when the instructions tell you to restart Dovecot.

Send your Linux system user a test message. This is the same user that you use for SSH. You should use the format .

Install Mailutils by entering the following command:

1apt-get install mailutils

Check your messages with Mailutils by entering the following command. You must be logged in as your own user, so drop out of root for now if you logged in as root earlier.

Type the number of the message you want to read.
Type quit when you want to exit your system user’s inbox.
If you succeeded in sending your system user a test message, you have successfully installed Postfix and configured it for the most basic mail delivery. By default, it delivers mail only for system users, and mail is stored in a file called /var/mail/myuser.

Basic Dovecot

In this section, you’ll install Dovecot and set it up so you can check your email for your system user over an IMAP or POP3 connection, which is the most basic configuration. This section is based on Dovecot’s Basic Configuration Guide, which is a great reference.

Install Dovecot and its IMAP and POP3 packages by entering the following command:

1apt-get install dovecot-core dovecot-imapd dovecot-pop3d

Open /etc/dovecot/conf.d/10-mail.conf for editing, and set the mail_location to the line shown below. This setting should direct Dovecot to look for mail in the same location where Postfix stores the mail, which should be /var/mail/myuser by default (Dovecot uses the variable %u so the correct username is used in the path). The mailbox format is designated as mbox.

/etc/dovecot/conf.d/10-mail.conf

1mail_location = mbox:~/mail:INBOX=/var/mail/%u

Also in /etc/dovecot/conf.d/10-mail.conf, set the mail_privileged_group to mail:

/etc/dovecot/conf.d/10-mail.conf

1mail_privileged_group = mail

In /etc/dovecot/conf.d/10-auth.conf, allow plain-text authentication by setting disable_plaintext_auth to no:

/etc/dovecot/conf.d/10-auth.conf

1disable_plaintext_auth = no

In /etc/pam.d/dovecot, tell Dovecot to use standard UNIX authentication. This means that your SSH username and password will also work for mail. Edit the file so it contains only the following:

/etc/pam.d/dovecot

1auth required pam_unix.so nullok account required pam_unix.so

Restart Dovecot.
Send yourself another test message.
Check your email. You can use either Telnet or a mail client. At this stage, your email address will be for your system user (myuser@example.com), and your username and password will be the same as they are for SSH (no @example.com part in the username at this stage). Your connection type will be standard (non-secure) and your password will be plain. You will probably have to set up your mail client manually, rather than through a wizard.

The Telnet and mail client tests will not work for root. Use a different system user.

If you succeeded in checking your mail over an IMAP or POP3 connection, you have successfully installed Dovecot and configured it for the most basic inbox access.

Virtual Domains and Users

Now that Postfix and Dovecot are working, you should set up virtual domains and users. Having virtual users for mail is an important step forward in the security and convenience of your mail server, because it eliminates the need to create a system user for everyone who needs a mailbox. It also makes it easier to add new domains and users to the mail server.

You’ll need to make quite a few configuration changes related to virtual domains and users in both Postfix and Dovecot. Postfix and Dovecot both need to be configured for virtual domains and users at the same time, because you’re changing the mailbox location, which needs to be coordinated between them. Here’s a general checklist of what you’ll be configuring in this section:

Make two new static files with the virtual user information (usernames, passwords, mailbox locations), one for Postfix and one for Dovecot. (You can’t use the same file because they require different parameters and formatting.) You didn’t need to write out your own authentication information before, because Postfix and Dovecot were just reading from the system authentication, but you need it now for virtual user authentication. Eventually you’ll be saving this information in MySQL databases, but it’s simpler to set it up in flat files for now.
Tell Postfix and Dovecot to use the virtual users.
List the virtual domains in the Postfix configuration file, instead of using the mydestination line.
Create the new mailboxes in their new locations. They used to be at /var/mail/myuser, but now they will be at /var/mail/vhosts/example.com/user/. This has the added bonus of letting you have the same username at different domains: for example, you can now have jane@example.com and jane@example.net be two different mailboxes.
Tell Postfix and Dovecot to use the new mailbox locations.
Grant one system user, called vmail, access to all the mailboxes, rather than having each system user own its own mailbox.
You may want to reference Postfix’s Virtual Readme and Dovecot’s wiki page on virtual users as you work through this section.

Create a virtual users file for Postfix. This will list all the email addresses and their delivery locations relative to the virtual_mailbox_base parameter (which gets configured in /etc/postfix/main.cf, which we’ll get to momentarily). We’re calling the file /etc/postfix/virtual_users_list, and it should look something like this:

/etc/postfix/virtual_users_list

1
2email1@example.com example.com/email1/
email2@example.com example.com/email2/

Create a virtual users file for Dovecot. This will list all your email usernames (just use the email addresses) and their passwords in plain text (obviously this is not production-ready). It should look something like this:

/etc/dovecot/users

1
2email1@example.com:{Plain}firstpassword
email2@example.com:{Plain}secondpassword

This list allows Dovecot to check the usernames and passwords for virtual users before granting them access to their inboxes.

Edit Postfix’s main configuration file, /etc/postfix/main.cf. Remove every domain except localhost from the mydestination parameter. Create a new parameter called virtual_mailbox_domains and add your domains:

/etc/postfix/main.cf

1virtual_mailbox_domains = example.com, hostname, hostname.example.com, localhost.example.com

There can be no overlap between the mydestination and virtual_mailbox_domains lists.

Also in /etc/postfix/main.cf, add the line virtual_mailbox_base and set it to /var/mail/vhosts so mail gets delivered to the new mailboxes. The final part of the path for each user is in the virtual_users_list file from Step 1.

/etc/postfix/main.cf

1virtual_mailbox_base = /var/mail/vhosts

Also in /etc/postfix/main.cf, add the line virtual_mailbox_maps and set it to the virtual users file you created in Step 1. It is a “hash” type file. If you’re following this example exactly, it will be:

/etc/postfix/main.cf

1virtual_mailbox_maps = hash:/etc/postfix/virtual_users_list

However, you can name this file anything you want, and set the virtual_mailbox_maps parameter accordingly.

The last change for /etc/postfix/main.cf in this section is to set up the new vmail system user. This user will own the virtual mailboxes. Add the following new lines:

/etc/postfix/main.cf

1
2
3virtual_minimum_uid = 100
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

Let’s take a moment to sum up all the changes that you just made in /etc/postfix/main.cf. You removed all the domains except localhost from the mydestination parameter, and added several new lines for the virtual domains and users, which should look like this (add the #Virtual domains comment if desired):

/etc/postfix/main.cf

1
2
3
4
5
6
7#Virtual domains
virtual_mailbox_domains = example.com, host
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/virtual_users_list
virtual_minimum_uid = 100
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

Now that you’ve made all the changes in the Postfix configuration files, you should make sure Postfix is reading the new settings with the following command:

1postmap /etc/postfix/virtual_users_list

Make the vmail user and group:

1
2groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /var/mail

Make the directory /var/mail/vhosts/example.com/email1 for every email address. You’ll have to start by making the vhosts directory and then work your way down. You can use mkdir with the -p flag if desired.

Change the ownership of the /var/mail directory and everything below it to the vmail user and group:

1chown -R vmail:vmail /var/mail

Great! Now the proper folders actually exist for mail delivery, and the user that owns those folders matches the one we told Postfix to use when writing new mail to the server.

Restart Postfix.

Try sending yourself a test message. Check /var/log/mail.log; you should see something like this:

/var/log/mail.log

1Mar 8 18:01:27 host postfix/virtual[4418]: E2C7528420: to=, relay=virtual, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)

The part that says relay=virtual means you’ve got virtual domains and users set up properly.

Next up is Dovecot. First, update the mail_location in /etc/dovecot/conf.d/10-mail.conf:

/etc/dovecot/conf.d/10-mail.conf

mail_location = maildir:/var/mail/vhosts/%d/%n

This sets the new mailbox location, /var/mail/vhosts/example.com/user. %d tells Dovecot to grab whatever is after the @ symbol from the person’s username when they log in, and %n tells it to grab whatever is before the @ symbol from the person’s username. This path MUST match the virtual_mailbox_base + /etc/postfix/virtual_users_list relative path in Postfix’s settings.

Now you have to tell Dovecot how to find and interpret our list of virtual users so that people can authenticate and access their inboxes. See Dovecot’s wiki article about virtual users in a flat file for more information. Add the following settings to /etc/dovecot/conf.d/auth-passwdfile.conf.ext:

/etc/dovecot/conf.d/auth-passwdfile.conf.ext

1
2
3
4
5
6
7
8passdb {
driver = passwd-file
args = username_format=%u /etc/dovecot/users
}
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}

The passdb section details how email users can authenticate. The driver line tells Dovecot you’re using a flat file, and the args line tells it where it is and what format to expect. (This is the /etc/dovecot/users file you made in Step 2.)

The userdb line tells Dovecot where to find the mail on the server and which system user it should use to access the mail files. Since the format for each mailbox’s location is the same, the userdb can be static. You’re telling it to use the vmail user to access the mailboxes. Finally, the home= parameter tells Dovecot to look for mail in var/mail/vhosts/example.com/user. This setting MUST match the virtual_mailbox_base + /etc/postfix/virtual_users_list relative path in Postfix’s settings. You have to tell Dovecot to look for mail in the same place you told Postfix to put the mail.

Now you just need to tell Dovecot to use auth-passwdfile.conf.ext instead of auth-system.conf.ext, so it uses that lovely new password file you created in Step 2. In /etc/dovecot/conf.d/10-auth.conf, add # to comment out the system user file, and remove # to enable the passwdfile config file:

/etc/dovecot/conf.d/10-auth.conf

1
2#!include auth-system.conf.ext
!include auth-passwdfile.conf.ext

Restart Dovecot.
Send yourself another test message.

See if you can check your email with IMAP or POP3; you can use a mail client or Telnet. You should now be able to use your email address and email password to log in, rather than your system username and password.

Remember that these three paths have to match: the virtual_mailbox_base + /etc/postfix/virtual_users_list relative path in Postfix’s settings, the mail_location in Dovecot, and the home= in Dovecot.

If your most recent test worked, you have now set up both Postfix and Dovecot successfully with virtual domains and users.

Dovecot’s LMTP for Local Delivery

Now that you have virtual domains and users working, it’s time to update the local delivery agent. By default, Postfix uses its own built-in LDA. We’re going to switch to using Dovecot’s LMTP (Local Mail Transfer Protocol) service instead. To do this, we have to set up a socket in Dovecot which Postfix can use.

See Dovecot’s wiki article about LMTP for the official documentation.

Install dovecot-lmtpd by entering the following command:

1apt-get install dovecot-lmtpd

In /etc/dovecot/dovecot.conf, add or modify the protocols line to look like the following. If you need to add the line, you can add it below !include_try /usr/share/dovecot/protocols.d/*.protocol.

/etc/dovecot/dovecot.conf

1protocols = imap pop3 lmtp

Carefully edit the existing service lmtp section of /etc/dovecot/conf.d/10-master.conf to look like the following, which will enable the socket:

/etc/dovecot/conf.d/10-master.conf

1
2
3
4
5
6
7
8
9
10
11
12
13service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0600
user = postfix
group = postfix
}
# Create inet listener only if you can’t use the above UNIX socket
#inet_listener lmtp {
# Avoid making LMTP visible for the entire internet
#address =
#port =
#}
}

Make sure you count your brackets. An extra or missing bracket in this section will produce a syntax error that prevents Dovecot from starting.

Restart Dovecot.

Make sure the socket exists:

1ls /var/spool/postfix/private/dovecot-lmtp

Now, tell Postfix to use the new socket for local delivery. In /etc/postfix/main.cf, set this line:

/etc/postfix/main.cf

1virtual_transport = lmtp:unix:private/dovecot-lmtp

Restart Postfix.
Send yourself a test message. Make sure you can still receive mail.
Authentication Hand-off from Postfix to Dovecot

By default, Postfix won’t let you send email unless you’re logged into the server directly. This is a good default, because you don’t want to become a spam hub. However, you want to loosen a production server’s settings slightly to let authenticated email users send mail. As a precursor to that, you need to set up authentication for Postfix. Since Dovecot already does a great job handling authentication when users want to check their email, you’ll let it handle authentication for Postfix as well.

This process is very similar to the one for LMTP, because you’re first creating a socket in Dovecot and then telling Postfix to use it. For more information, see Dovecot’s wiki article about Postfix and SASL.

Carefully edit /etc/dovecot/conf.d/10-master.conf to look like the following, which will enable the socket:

/etc/dovecot/conf.d/10-master.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26service auth {
# auth_socket_path points to this userdb socket by default. It’s typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Its default
# permissions make it readable only by root, but you may need to relax these
# permissions. Users that have access to this socket are able to get a list
# of all usernames and get results of everyone’s userdb lookups.
unix_listener /var/spool/postfix/private/auth {
mode = 0666
user = postfix
group = postfix
}

unix_listener auth-userdb {
mode = 0600
user = vmail
#group =
}

# Postfix smtp-auth
#unix_listener /var/spool/postfix/private/auth {
# mode = 0666
#}

# Auth process is run as this user.
#user = $default_internal_user
}

Again, watch your brackets.

In the service auth-worker section, set user to vmail.

/etc/dovecot/conf.d/10-master.conf

1
2
3
4
5
6service auth-worker {
# Auth worker process is run as root by default, so that it can access
# /etc/shadow. If this isn’t necessary, the user should be changed to
# $default_internal_user.
user = vmail
}

Restart Dovecot.

Check that /var/spool/postfix/private/auth exists by entering the following command:

1ls /var/spool/postfix/private/auth

Now you’ll configure Postfix to use Dovecot’s authentication. For more information, see Postfix’s Dovecot SASL guide and Postfix’s guide on enabling SASL. Add the following lines to /etc/postfix/main.cf. This tells Postfix the authentication type, the location of the socket, and that SASL authentication should be enabled:

/etc/postfix/main.cf

1
2
3smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

Restart Postfix.
Send yourself a test message and make sure you can still receive it.
If your test succeeds, you’ve just finished setting up Dovecot’s LMTP service as your local delivery agent.

SSL Encryption

Now that authentication is set up, let’s make sure the authentication process is secure. To do this, you’ll require all authentication attempts to be encrypted with SSL or STARTTLS. For more information, see Dovecot’s wiki article on SSL encryption.

Open /etc/dovecot/conf.d/10-ssl.conf for editing, and then set ssl to required:

/etc/dovecot/conf.d/10-ssl.conf

Also in /etc/dovecot/conf.d/10-ssl.conf, check the paths to the SSL certificate and key. They should be set to Dovecot’s certificate and key by default. If that’s what you’re using, leave these settings be. Otherwise, update the paths to the certificate and key you want to use.

/etc/dovecot/conf.d/10-ssl.conf

1
2ssl_cert =

Excerpt from: Troubleshooting Problems with Postfix, Dovecot, and MySQL – Linode

Cheapest Car Insurance Quotes

Early Bird Pricing for MySQL Central @ Oracle Open World …

by Lanh on July 30, 2014

Register before August 1st for early bird pricing!
Millions of organizations around the world trust MySQL to power their business-critical web, cloud, and embedded applications. Want to learn best practices to develop next-generation applications with MySQL? Joins us at MySQL Central @ OpenWorld.
HighlightsLearn new skillsShare and network with the global MySQL communityHear about new MySQL features directly from OracleGet insight on product roadmapsHave fun

More here: Early Bird Pricing for MySQL Central @ Oracle Open World …

Diet Tips

Chicago MySQL Meetup August 4th | Open Source DBA's Blog

by Lanh on July 30, 2014

High Availability With MySQL – Jay Janssen of Percona
Monday, August 4, 20146:00 PM
GrubHub111 W. Washington St.Suite 2100Chicago, IL
Come join Jay Janssen, Principal Consultant at Percona as he speaks about High Availability with MySQL. Jay has been with Percona since 2011. Before that, spent 7 years working for Yahoo in a variety of fields including High Availability architectures, MySQL training, tool building, global server load balancing, multi-datacenter environments, operationalization, and monitoring.
Pizza and beverages will be provided.

About these ads

div { margin-top: 1em; } #google_ads_div_wpcom_below_post_adsafe_ad_container { display: block !important; }
]]>

The rest is here: Chicago MySQL Meetup August 4th | Open Source DBA's Blog

Where Can I Compare Car Insurance

Using Sysbench to Benchmark MySQL – Docker – Flux7

by Lanh on July 29, 2014

During our earlier benchmarking activities, we benchmarked applications using wikibench. Remember that wikibench is a web application on a traditional LAMP stack. While analyzing the results, we found that the performance is improved by tuning the MySQL database. This motivated us to benchmark MySQL.
To carry out this process, we used sysbench to benchmark MySQL. Sysbench is a modular, cross-platform and multi-threaded benchmarking tool. It’s used to benchmark CPU, file I/O, threads (scheduler performance), mutex and OLTP. This tool is especially useful if you are trying to setup and test a server for intense database usage.
You can install this tool on an Ubuntu machine using the following command:

You can get detailed information about available options by typing this command:

Even though sysbench is used for various kinds of benchmarking, in this post, we are focusing on using sysbench to benchmark OLTP on a MySQL server.
So, let’s get started. Here are the details of the machine and the OS:
Machine: AWS m3.large, 2 VCPUs, 7GB RAM and 64-bit arch
OS: Ubuntu 14.04 LTS (kernel version: 3.13.0-24-generic)
Preparing for the Test
Of course, we must first install MySQL server on the machine. We need to create a test database on which the benchmarks will run. This is easily done using the following command:

Once the database is created, we prepare the test by creating a test table and populating the table with data. This is done by using the following command:

By using this command, it creates a basic table. Its default name is ‘sbtest.’ Following is the table command use to create it. (All of these details are available in the sysbench user manual).
CREATE TABLE `sbtest` (
`id` int(10) unsigned NOT NULL auto_increment,
`k` int(10) unsigned NOT NULL default ’0′,
`c` char(120) NOT NULL default ”,
`pad` char(60) NOT NULL default ”,
PRIMARY KEY (`id`),
KEY `k` (`k`);
)
The table we created is then filled with a specified number of rows. By default, the storage engine we used is InnoDB. If you want to test it using other storage engine types, you can specify which type by using the optional parameter: ‘–mysql-table-engine=’.
Running the Test
Next, we test the run using the following command:

The following is very important. Here is a brief explanation of some of the parameters:
–oltp-test-mode: There are three types of test-modes:
simple: Each thread runs simple select queries of the form. Consider:
SELECT c from sbtest where id = n
complex: Each thread runs advanced transactional queries, including range queries, range SUM, range ORDER by, inserts and updates on index, as well as non-index columns, delete rows.
nontrx: Non-transactional; this is similar to simple, but you can choose the query to run. Unlike advanced transactional, however, it does not preserve the test table between requests.
–num-threads: Number of worker threads to create.
–max-time: Limit for total execution time in seconds.
–max-requests : Limit for total number of requests. “0” means unlimited; (default equals 10000).
Clean Up After the Test
Once the tests are completed, sysbench cleans up the table it created during the ‘prepare’ stage. Clean up is done using the following command:

Sample Output
A sample output of the sysbench run is shown below. A few key things to look for are highlighted in blue:
Transactions per second
Per request statistics

There it is. A complete outline of our results using sysbench to benchmark MySQL.
Do you have any questions? If so, please send your inquiries to info@flux7.com. What’s more, don’t hesitate to comment on this post or any of the actions we took to do the testing we described. We are always looking for an opportunity to have a productive sharing of knowledge.
You can also learn more about our other benchmarking activities by visiting us at flux7.com.

View post: Using Sysbench to Benchmark MySQL – Docker – Flux7

Cheapest Car Insurance Phone Quotes

How to Manage MySQL with cPanel

by Lanh on July 28, 2014

Hello,There are several ways to manage MySQL databases. Among them are direct command-line manipulation, web-based interfaces such as phpMyAdmin and remote database administration tools. You can also manage some MySQL functionality from within your hosting control panel, if you are using cPanel.cPanel database management is found in Home >> Databases >> MySQL Databases. A number of quick and easy functions are available to you, including:Create a DatabaseCheck a Database for ErrorsRepair a DatabaseCreate a Database UserDefine a Users PrivilegesSearch DatabaseDelete a DatabaseEvery database in MySQL needs to be associated with a user who can manipulate it. Otherwise, only the root user will have access to it. The first step is to create the database as follows:Type the name of a database into the box labeled: New DatabaseClick Go BackGo to MySQL UsersEnter a username under Add New UserEnter a password or use the Password Generator to create oneRetype the passwordClick Create UserOnce you have created the user, you need to associate it with the database you created in the Define a Users Privileges section. Follow these steps:In the section labeled Add User to Database, choose the user you want to add from the menuSelect the database from the Database menuClick AddOn the next screen, you will need to set the privileges you want to grant or select All PrivilegesClick Make ChangescPanels MySQL administration cannot replace a full MySQL administration program, but it can give you the basic functionality you need to get databases up and running. For complete documentation, see the cPanel online docs website.Thanks.

Continue reading here: How to Manage MySQL with cPanel

snabb viktminskning

Refactoring MySQL Cursors – O'Reilly Network Articles

by Lanh on July 28, 2014

Hi All,My name is Roland Bouman, and I’m a certification developer for MySQL AB. This is my first post on the O’Reilly database weblog, and I figured it would be nice to start with a technical article about MySQL cursors, a subject I have written about before on my blogger weblog.The first part of this article explains why cursors are usually unnecessary.A few common problems with cursors are briefly discussed. Also, typical stored procedure pattern is described that uses a cursor, and a demonstration is given that shows how it can be refactored to an equivalent procedure that uses a single SQL statement instead.In the second part of this article, the negative performance implications of using cursors are illustrated with a few benchmarks,and the cases where a cursor might be useful after all are briefly discussed.

Jason P Sage2007-01-08 08:26:41

Nice Article. I’ve always believed cursors were a bit much and that SQL itself is fairly powerful in it of itself.Also I tend to think that when you stick with SQL itself, versus getting to caught up with DBMS specific implementations – like cursors – that you end up that much more portable across different platforms.

Anne2007-08-26 00:56:09

It was interesting to read

Igor2007-11-26 16:46:50

Great article, thanks!Hey, a minor thing – in the very last code snippet you should probably replace r.id_res with l.id_res.

Vlad GURDIGA2008-04-10 09:23:37

I never knew that there is something like UPDATE with JOINs, but today it just saved my life!! Greeaaat article!

Read more: Refactoring MySQL Cursors – O'Reilly Network Articles

Recipes for breakfast

PostgreSQL enhancements aimed at luring skittish MySQL users …

by Lanh on July 28, 2014

Four and a half years after Oracle Corp. completed the acquisition of Sun Microsystems, MySQL continues to cast a formidable shadow over the web database market despite losing much of its original open-source character under Oracle’s new ownership. But to say that the buyout has not been felt in the ecosystem would be an understatement.
A growing number of users, including prominent tech firms such as Google and Red Hat, Inc., have already moved or are in the process of moving their data from MySQL to community-led alternatives that aren’t controlled by any one vendor. While Oracle has committed to maintaining an open source version of MySQL, the user community has had his doubts about the company’s sincerity. This has put wind in the sails of historic underdog PostgreSQL, which is now finally hitting its stride but still lacks many of the capabilities needed to fulfill its potential to plug the hole left in the wake of the Sun acquisition.
EnterpriseDB Corp., a top distributor of the open-source platform, is trying to change that, one new feature and performance improvement at a time. The latest batch of enhancements announced by the company mark another  big step in the right direction.
The most notable addition is a new Foreign Data Wrapper, or FDW, for Hadoop that allows users to pull in data from their analytic clusters utilizing familiar SQL syntax without going through the trouble of cobbling together a connector from scratch. The extension levels the playing field in this area against Oracle, which added support for the batch processing framework to MySQL last April. It also lowers the technical barriers that have made managing databases a painful task  in the past.
The new Hadoop connector, set to hit general availability in fall, is joined by  a revamped wrapper for MongoDB. Both take advantage of the FDW upgrade introduced with the 9.3 release of PostgreSQL, which EnterpriseDB says speeds response times and helps keep code maintainable through the use of a formal client library specification.
The extensions were unveiled in conjunction with a pair of new tools that the company is releasing to the community in a bid to smooth out some of the trickier aspects of managing PostgreSQL environments. The first of the free utilities – pg_catcheck – is a diagnostics engine that scans the metadata used to keep track of database objects for errors and inefficiencies. The other solution – pg_hiberantor – helps maintain consistent performance after a failure  by automatically restoring the data held in cache at the time of the shutdown.
EnterpriseDB is also updating two of its premium products to further simplify life for administrators. Replication Server 5.1 reduces latency, provides more room to scale across clusters, makes it easier to search rows and allows users to define custom policies for how to handle data conflicts, according to the firm. EDB Failover Manager 1,1, meanwhile, adds an advanced authentication capability and comes with new agents that run as operating system services so to stay available even when the database itself goes down.
photo credit: Thomas Hawk via photopin cc

More: PostgreSQL enhancements aimed at luring skittish MySQL users …

Cheapest Car Insurance Mobile

Port 25 How-To: Install MySQL on Windows Vista – O'Reilly Media

by Lanh on July 28, 2014

Chris Travers, who wrote the recent Port 25 tutorial for installing PostgreSQL on Windows, is back again with a tutorial describing how to install MySQL on Windows Vista. You can find the paper linked in a Port 25 blog entry from Jamie Cannon at titled…MySQL on Windows: Configuration & InstallChris’ paper focuses on installing MySQL on Windows Vista because its new security features require a few tweaks to allow MySQL to install properly. The general information provided in the paper could also be applied to Windows Server, however.Since it isn’t discussed in the paper, I thought I’d mention that MySQL comes in two flavors now: The Enterprise Edition appeared late last year (2006) and has a tiered pricing depending on the kind of support desired. The Community Edition is still a free download. However, the two editions have forked in a way that appears similar to the relationship between Red Hat Enterprise Edition (RHEL) and Fedora Core.MySQL Enterprise Edition is the version MySQL recommends for use with mission critical applications. It is said to be more stable and will have minor point releases available as a binary download for the various supported platforms.MySQL Community Edition does not have formal support options from MySQL. It will include new features before the Enterprise Edition and can be, I guess, considered be the testing ground version. Binary ready to run installation files will only be released twice a year for this version.The two versions will converge about every 18 months and then fork again for the next round.I used to install/upgrade MySQL using the RPM releases from MySQL. However, since the code was forked, I have been installing MySQL for Linux from source code which is released for every minor point version. One minor issue on the Linux side of the world is that the RPM installer assumes the socket file is located at /var/lib/mysql/mysql.sock while the source code version points to /tmp/mysql.sock. Tweaking the my.cnf file for MySQL and php.ini for PHP takes care of this from a LAMP point of view. I haven’t tried to build from source for Microsoft Windows.

Bisheshwar2007-08-28 22:30:21

After installing MySQL 5 on Vista Business,MySQL Monitor could not be startup. If any solution, please tell me.bisheshwars@yahoo.com
Todd Ogasawara2007-08-29 00:17:35

Just a guess that Vista’s security model is tripping it out. Check MySQL Monitor’s properties and set it to run as Administrator.

abiola2007-09-09 06:05:27

After installing MySQL 4.1 on Vista Business,MySQL Monitor could not be startup. If any solution, please tell me.Email-abiosson@yahoo.ca
Johnny2008-02-04 08:50:05

I have programmed in physics+3d in Flash.I have created guestbooks and rsvp forms with ASP, PHP, and APACHE.I can still say that installing MySQL on my 32-bit Vista Computer has been the hardest thing I’ve ever done with technology.

Malta2008-04-02 01:55:15

I installed mysql 5 on my machine, which has vista, but it’s not letting me configure it. Whenever I hit the configure button within the start menu an error is popping up. Can anyone help pls? thx

Read more: Port 25 How-To: Install MySQL on Windows Vista – O'Reilly Media