Let us now configure Dovecot which will do several things for us:
- get emails from Postfix and save them to disk
- watch quotas (how much space a user may use on your disk)
- execute user-based "sieve" filter rules (can be used to put away emails to different folders)
- allow the user to fetch emails using POP3 or IMAP
Before we get to the actual configuration for security reasons it is suggested you create a new system user that will own all virtual mailboxes. The following shell commands will create a system group "vmail" with GID (group ID) 5000 and a system user "vmail" with UID (user ID) 5000. (Make sure that UID and GID are not yet used or choose another - the number can be anything between 1000 and 65000 that is not yet used):
$> groupadd -g 5000 vmail $> useradd -g vmail -u 5000 vmail -d /var/vmail -m
The configuration files for Dovecot are found under /etc/dovecot. Start with the main file...
/etc/dovecot/dovecot.conf
See the line protocols and define the protocols you want to offer. By default this line reads:
protocols = imap imaps pop3 pop3s
so that Dovecot starts the IMAP and POP3 services and also its equivalents that work over an encrypted SSL (secure socket layer) connection.
Although this is a less secure setting you will probably still need it:
disable_plaintext_auth = no
This will allow plaintext passwords over an unsecured (non-SSL) connection. By default it is set to 'yes' for security reasons. Setting it to 'no' will mean less security but may help users of a "certain" Microsoft email software that is broken in many ways.
A more important setting is:
mail_location = maildir:/var/vmail/%d/%n/Maildir
which will tell that the users' mailboxes are always found at /var/vmail/DOMAIN/USER/Maildir and that it should be in maildir format.
There is already a section "namespace private" in your dovecot.conf which is commented out by "#" characters. The "private" namespace is the personal mailbox this is only available for a certain user. You can leave this section disabled and get a maildir directory schema like:
/var/vmail/christoph.haas/email/Maildir/.spam
If you followed previous ISPmail tutorials then your directories may be different. If you rather have:
/var/vmail/christoph.haas/email/Maildir/.INBOX.spam
then you need to declare that in the "namespace private" section as follows. Enable this section and make sure these variables are set:
namespace private {
separator = .
inbox = yes
}
Next look for a section called "auth default". First define the allowed authentication mechanisms:
mechanisms = plain login
As you browse through the section you see many backends that Dovecot can access to get the email users' data. Inside this section you need to set:
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
which tells Dovecot that the passwords are stored in an SQL database and:
userdb static {
args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
}
to tell Dovecot where the mailboxes are located. This is similar to the mail_location setting. The user gets authenticated in the "passdb sql" section. So the "userdb static" section defined where the mail folders are located. Using "userdb sql" is not needed as all mailboxes follow a fixed directory schema.
You will want to comment out the section called "passdb pam that deals with system users. Otherwise Dovecot will also look for system users when someone fetches emails which leads to warnings in your log file.
Now look for another section called socket listen. Here you define socket files that are used to interact with Dovecot's authentication mechanism. Make the section read:
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
}
}
The "master" section is needed to give Dovecot's delivery agent (the program that saves a new mail to the user's mailbox) access to the userdb information. The "client" section creates a socket inside the "chroot" directory of Postfix. chroot means that parts of Postfix are jailed into /var/spool/postfix and can only access files in that directory or its subdirectories. It is a good security measure so that even if Postfix had bugs and were hacked then the attacker would not be able to access /etc/passwd for example because it's outside of /var/spool/postfix.
And finally the "protocol lda" section needs to be customized. The LDA (local delivery agent) is more capable than Postfix's built-in virtual delivery agent. It allows for quotas and Sieve (ships with the dovecot-common package) filtering. Let the section be:
protocol lda {
log_path = /var/vmail/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@example.com
mail_plugins = cmusieve
}
Please change the above postmaster email address to a valid address where the administrator can be reached.
The log_path setting is optional but may help you figure out why a certain server-side filter is not doing what you expect. As the dovecot-deliver.log may grow pretty fast you should create a logrotate configuration file /etc/logrotate.d/dovecot-deliver for it:
/var/vmail/dovecot-deliver.log {
weekly
rotate 14
compress
}
Edit the /etc/dovecot/dovecot-sql.conf and change these settings:
driver = mysql connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuser2009 default_pass_scheme = PLAIN-MD5 password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
Restart Dovecot:
$> /etc/init.d/dovecot restart
Now look at your /var/log/mail.log logfile. You should see:
dovecot: Dovecot v1.0.rc15 starting up dovecot: auth-worker(default): mysql: Connected to 127.0.0.1 (mymailserver)
Before you send a first test email you will need to fix file system permissions for the /etc/dovecot/dovecot.conf file so that the vmail user can access the Dovecot configuration. The reason is that Postfix starts the delivery agent with vmail permissions:
$> chgrp vmail /etc/dovecot/dovecot.conf $> chmod g+r /etc/dovecot/dovecot.conf
65 Comments
User dovecot in group mail?
Submitted by Anonymous (not verified) on
The Dovecot documentation (http://wiki.dovecot.org/VirtualUsers) explicitly states: "The most important thing you need to understand is that Dovecot doesn't access the users' mails as the dovecot user! So don't put dovecot into the mail group, and don't make mails owned by the dovecot user. That will only make your Dovecot installation less secure."
What is the reason to add the dovecot user to the mail group? I don't think I see anything stated on this page?
Thanks for the hint. I
Submitted by Christoph Haas on
Thanks for the hint. I believe that Dovecot failed to access the mail directories here unless I added it to the "mail" group. This is the only hint I found in Dovecot's README.Debian.gz:
Can you verify that your mail server delivers email correctly even if the group is not assigned? I currently lack a decent test server and will have to setup a new one. Thanks.
Hi, I can indeed confirm that
Submitted by Anonymous (not verified) on
Hi,
I can indeed confirm that mail delivery worked correctly on my test server even if dovecot is not a member of the mailgroup.
The parameter
mail_privileged_group = mailis set by default and I have not changed it. However since /var/vmail is owned entierly by user vmail (who is not a member of group mail either) I don't think this particular setting would have any effect even if "either [INBOX's] initial creation or dotlocking fails". The mail group has no business accessing or modifying /var/vmail.
Investigating further: Postfix calls the deliver program as user vmail and group vmail in our case, doesn't it? From pipe(8):
user=username:groupname Execute the external command with the user ID and group ID of the specified username. The software refuses to execute commands with root privileges, or with the privileges of the mail system owner. If groupname is specified, the corresponding group ID is used instead of the group ID of username.So there really is no need to put dovecot in the mail group. It wouldn't even have any effect on the deliver process at all if I understand correctly.
Something else, probably related: Why did you choose /var/vmail as base directory for virtual mail storage? Why not /var/mail/vmail? Just curious :)
And thanks for your great articles! I've known them for years and now have the opportunity to implement a virtual mail hosting setup based closely on this latest incarnation. Expect some more comments and questions :)
Thanks a lot for your
Submitted by Christoph Haas on
Thanks a lot for your investigation. I'll remove it then. Seems I have mis-researched that detail.
The reason I did not choose /var/mail/vmail/ is that a system user "vmail" would get its mail to delivered to a file /var/mail/vmail. And somehow it feels wrong. /var/mail is IMHO the location for mailboxes of system users. And I believe that /var/vmail is at least better than /home/vmail.
I welcome your suggestions and comments. It's likely that I missed further details while keeping track of the "big picture". ;)
userdb static
Submitted by Anonymous (not verified) on
Hello Christoph,
Absolutly super howto
I have qustion about automake MailDir.
I have some problem. If I testing my mailserver, I make small mistake (bad uid and gid in dovecot.conf and mailserver send and make Maild to not exist user.
In you test example
1. send mail from Steve to John
2. server cant drop mail to maildir John and send to Steve back information about it. (only to spool)
3. I correct mistake
4. server make correctly Maildir for John
5. But make Maildir for Steve (steve is not in SQL virtual_users and is not user)
Where I define automake ? Will be spam make Maildirs for not exist users ? What is allow_all_users=yes
Thanks
"automake" is enabled by
Submitted by Christoph Haas on
"automake" is enabled by default. Please direct your support question to the mailing list.
plain auth enabled
Submitted by Anonymous (not verified) on
hello,
i followed your great tutorial about a week ago and i was very pleased to see that (nearly) everything worked perfectly right from the beginning...
then i discovered, that new created accounts could not send mails saying:
554 5.7.1 <email@example.com>: Relay access denied
after some research i found out that this error message is actually misleading... the problem was that for sending mails via smtp the plain authentication is disabled by default.
and because you set the parameter
disable_plaintext_auth = no
in the dovecot config... you should perhaps also set the postfix to allow plain text authentication in main.cf:
smtpd_tls_auth_only = no (instead of yes)
just an idea... thanx again for your great tutorial!! kepp that great work up!!
chris
Right
Submitted by Christoph Haas on
Thanks, you are totally right. And I discovered that even on my test server I have set "smtpd_tls_auth_only = no" for obvious reasons. I have fixed that in the tutorial now.
Patch
Submitted by Anonymous (not verified) on
After few days of this config I saw in my /var/vmail thousand of new folders like "xy3w4xxf4, sdaa3d3, xvv323b" and that was brute force attack on pop3 when they try to login dovecot creates new folder for them... With this patch its fixed...
You should patch this tutorial as follows:
dovecot.conf (comment and add this)
#userdb static {
# args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
#}
userdb prefetch {
}
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
dovecot-sql.conf (new line)
user_query = SELECT email as user, password, 5000 as uid, 5000 as gid, '/var/vmail/%d/%n' as home FROM view_users WHERE email='%u';
~# chown -R 5000:5000 /var/vmail/
Bug?
Submitted by Anonymous (not verified) on
I see the tutorial still has 'allow_all_users=yes' set. It would be nice to know what the status of the above "patch" is. Or at the very least a clarification on why 'allow_all_users=yes' is required.
The dovecot.conf file says, "If you use deliver, it needs to look up users only from the userdb. This of course doesn't work with static because there is no list of users. Normally static userdb handles this by doing a passdb lookup. This works with most passdbs, with PAM being the most notable exception. If you do the user verification another way, you can add allow_all_users=yes to the args in which case the passdb lookup is skipped."
Required?
Submitted by Anonymous (not verified) on
I think it is not required.
Roundcube can send email to nonexistent mailbox and I think this option is a problem. I will remove this allow_all_users=yes setting and I hope this will solve the problem
A security issue
Submitted by Anonymous (not verified) on
This seems like a security issue with this tutorial. I've been stuck configuring my Dovecot install for a couple days now and, the more I learn, the more I'm convinced this section of the tutorial isn't very well done.
I've found this URL to be very helpful for figuring out MySQL integration:
http://wiki.dovecot.org/UserDatabase/Prefetch
Which boiled down to:
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
userdb prefetch {
}
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
Then in /etc/dovecot/dovecot-sql.conf:
driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuser2009
default_pass_scheme = PLAIN-MD5
password_query = SELECT email AS user, password, 5000 AS userdb_uid, 5000 AS userdb_gid, '/var/vmail/%d/%n' AS userdb_home FROM virtual_users WHERE email = '%u';
user_query = SELECT email AS user, password, 5000 AS uid, 5000 AS gid, '/var/vmail/%d/%n' AS home FROM virtual_users WHERE email = '%u';
That seems like a good approach based on the aforementioned Wiki URL, the "Patch" above, the tutorial, and the comments in dovecot-sql.conf. It is what I plan on using instead of 'static' and the queries seem to run fine for me.
I understand your
Submitted by Christoph Haas on
I understand your point and will thoroughly test that in the Squeeze tutorial. But whatever I try... even with attempting to invent usernames - I don't get additional random directories like you did.
allow_all_users=yes
Submitted by Anonymous (not verified) on
According to the Dovecot MainConfig description, Dovecot can't do username lookups when userdb static is enabled. So, it uses the passdb configuration to do lookups. In our case, we do not need allow_all_users=yes, because we are using the passdb to do user lookups. If we were doing the lookups a different way, then we would allow_all_users.
static settings generated from template UserDatabase/Static
# args = uid=500 gid=500 home=/var/mail/%uIf you use deliver, it needs to look up users only from the userdb. This of course doesn't work with static because there is no list of users. Normally static userdb handles this by doing a passdb lookup. This works with most passdbs, with PAM being the most notable exception. If you do the user verification another way, you can add allow_all_users=yes to the args in which case the passdb lookup is skipped.
Great tut Christoph
large and lowcase
Submitted by Anonymous (not verified) on
First of all a very big thx for the nice tut.
But i have a big problem i think this is a dovecot problem.
E.g. the user test@com.com access all will be fine so he find his mails.
But when he type Test@com.com he found an empty mailfolder. Just right Dovecot creates a NEW Folder like Test instead using test
Anyone an idea?
This is easily fixable by
Submitted by Anonymous (not verified) on
This is easily fixable by correcting the password query in dovecot-sql.conf. It should look like this:
Christoph should update the tutorial for this change; not selecting the email address as the user attribute (email AS user) makes Dovecot discard the attribute althogether and use the user-supplied email address/username instead. This address/username may or may not use the correct case, leading to potential problems like you discribed.
There is also a thread in the workaround-chitchat mailing list and another one in the Dovecot mailing list on this topic.
Thanks
Submitted by Christoph Haas on
Fixed in the tutorial. Thank you for the research.
Also can use %Ln and %Ld in
Submitted by Anonymous (not verified) on
Also can use %Ln and %Ld in path
Password problem
Submitted by Anonymous (not verified) on
Re: Password problem
Submitted by Anonymous (not verified) on
This can be fixed by placing quotation marks around the RHS of the connect statement:
connect = "host=127.0.0.1 dbname=mailserver user=mailuser password=hack#me"
error on line 1017 (section changed at line 971
Submitted by Anonymous (not verified) on
Hello , i have a problem configuring my dovecot.conf file . i get the following error Error in configuration file .../dovecot.conf
At line 971 is the userdb static clause . What should i do to the configuration that will make dovecot start working ?
Brackets?
Submitted by Christoph Haas on
First check that all brackets are closed. No "{" without a "}". That's a common problem because the sections are large and nested.
playin login?
Submitted by Anonymous (not verified) on
Hi,
thanks for this very useful tutorial. But I have a question.
You write auth default { mechanisms = plain login ...
So the login is in plain text. Is this correct? Is it possible to make this encrypted?
disable_plaintext_auth
Submitted by Christoph Haas on
You can enforce encryption by setting disable_plaintext_auth as explained above.
"passdb pam"
Submitted by Anonymous (not verified) on
I use "Roundcube" as webmail, thats very pretty.
With this default setup it was extremely fast. I needed to comment out the
passdb pam {
}
part form the dovecot.conf. Thats no problem because this config-section is default empty.
Regards,
Robert
Mail ending up in /var/mail/username by mistake
Submitted by Anonymous (not verified) on
My only issue so far is that my mail is being stored in /var/mail/username and not /var/vmail/Domain/username/Maildir.
I've gone back over all my settings and I can't see any discrepancies from your settings to explain it.
The only major difference I have noted is that procmail appears to be handling the send when I complete the telnet smtp example.
Instead of:
status=sent (delivered via dovecot service)
I'm seeing:
status=sent (delivered to command: procmail -a "$EXTENSION")
procmail?
Submitted by Anonymous (not verified) on
Please check that your domain wasn't accidentally listed in "mydestination". You should get loads of warnings about that in your mail.log.
Thanks for replying. I'm not
Submitted by Anonymous (not verified) on
Thanks for replying. I'm not seeing any errors in mail.log at all. The mail appears to be handled fine, it just insists on shunting it to the wrong mailbox location.
I took another look at $mydestination in the main.cf and it reads:
mydestination = mailserver.myipname.com, localhost.myipname.com, localhost, myipname.com
I tried different combos of these, and the only way that incoming mail would get through is if myipname.com is in the list (either by itself, or with any of the other 3).
For what it's worth, the rest of the main.cf file following mydestination reads as thus (note the procmail reference);
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
local is bad
Submitted by Anonymous (not verified) on
"relay=local" means that your email was delivered locally. You don't want that. I'm sure that one of the domains you defined as local (mydestination) is the domain in question.
Christ on a bike. Turns out
Submitted by Anonymous (not verified) on
Christ on a bike. Turns out my problem was related to a typo in the virtual_domains table. Only took me 10 days to notice it. I'm an idiot. Thanks for your help.
Matt
cmusieve --> sieve
Submitted by Anonymous (not verified) on
Hola, you might wanna change the value of cmusieve into sieve on this tutorial page ;c)
Otherwise you might end up with a:
Fatal: Plugin cmusieve not found from directory /usr/lib/dovecot/modules/lda
in /var/vmail/dovecot-deliver.log
NB. Version 1.2 and higher use new plugin named sieve
Not for Lenny
Submitted by Christoph Haas on
In Lenny the plugin is called "cmusieve" so you mustn't change that.
Newer versions (Squeeze) changed that to sieve. But that requires more changes than just the name. I'll deal with that in the next tutorial.
Debian Squeeze
Submitted by Anonymous (not verified) on
But that requires more changes than just the name. I'll deal with that in the next tutorial.
Oh snap! I thought changing the name would be sufficient. Since I'm just setting up my mail server on Debian Squeeze, would it be possible for you to outline what I have to watch out for? Any keywords to google? Or should I just skip some part of the tutorial?
Would be very, very nice if you (or someone else) cold help me!
README.Debian
Submitted by Christoph Haas on
This file will help you (from Debian "squeeze"): /usr/share/doc/dovecot-common/README.Debian
See the "Upgrading from 1.0 (lenny) to 1.2 (squeeze)" section:
Upgrading from 1.0 (lenny) to 1.2 (squeeze)
--------------------------------------------
Several configuration file values have changed between releases. If the
local configuration contains any of the following changed values they
should be updated to use the new name/value according to the documentation
at http://wiki.dovecot.org/Upgrading/1.1 and
http://wiki.dovecot.org/Upgrading/1.2. The most common values that need to
be changed are:
1.0 to 1.1
----------
* listen = [::] listens only for IPv6 connections now, if you want both
IPv4 and IPv6 use listen = *, [::]
* Quota plugin has completely new configuration. See
http://wiki.dovecot.org/Quota/1.1
1.1 to 1.2
----------
* The SIEVE plugin was changed from using a cmusieve-derived plugin to a
native dovecot plugin. The configuration properties are identical,
however the plugin name has changed. To support the SIEVE plugin in 1.2:
a) replace 'cmusieve' with 'sieve' in the mail_plugins value
of the lda protocol in the config file.
b) edit all sieve scripts to change the following requires (see
http://wiki.dovecot.org/LDA/Sieve/Dovecot#Migration_from_CMUSieve)
i. replace imapflags with imap4flags
ii. convert notify usage to the new enotify
* Renamed ssl_disable=yes to ssl=no.
* Renamed auth_ntlm_use_winbind to auth_use_winbind, which also determines
if GSS-SPNEGO is handled by GSSAPI or winbind.
* The sieve= and sieve_storage= settings need to be placed in the plugin
{} section now and sieve_storage= needs to be renamed to sieve_dir=.
This removes the duplication of these values with respect to the Sieve
Plugin for deliver. So, if using the Sieve plugin, these settings should
already be there and all that needs to be done is remove the sieve= and
sieve_storage= settings from the protocol managesieve {} section.
Thanks!!
Submitted by Anonymous (not verified) on
Hey, that was fast! Thank you very, very much, again!
Once my new server is up and running, I guess I will find the time for a little donation ... ;)
:)
Submitted by Christoph Haas on
Hehe, thanks. :) Glad it helped.
allow_all_users
Submitted by Anonymous (not verified) on
I wonder why allow_all_users=yes is needed. dovecot is configured to use the passdb for lookup, correct?
I ask because I recently ran into a curious issue: I get spam email from fake addresses at my own domain. I.e. boipeloackland@mydomain sends a spam mail to me@mydomain, which is an alias that redirects the mail to my actual main address on another server. That server's spam protection bounces the message. At this point, my postfix server at "mydomain" delivers the bounce to "boipeloackland@mydomain", creating a maildir for that user, apparently no longer bothering to validate the adress against virtual_alias_maps or virtual_mailbox_maps.
Setting allow_all_users=no fixes the issue for me, but I'm wondering whether I am overlooking any side effects, or whether this is maybe even possible to fix on the postfix side.
user naming and description don't match
Submitted by Anonymous (not verified) on
hi,
you might want to change the description text of seting up an system user named "user".
in the describing text you tell it will be "user" in the following commands you set up a user named "vmail".
bye
Thanks. Fixed.
Submitted by Christoph Haas on
Thanks. Fixed.
dovecot creates maildirs for virtual aliasses!
Submitted by Anonymous (not verified) on
SInce i change some postfix stuff (mydestination canonical domain moved from mydestination to virtual_alias_domains in mysql from your tutorial!) my dovecot delivers aliases for mailboxes in seperate mailboxes. I use the patch at the bottom to prevent dos pop3/imap attacks, because i found maildirs a lot of them a few days ago, but the forwarding from an alias to a mailbox has worked correctly since a few hours, now i insert in virtual_aliases a new alias as a destination a mailbox listed in virtual:users and after getting a mail i have a new maildir in /var/vmail/diomain/<newmaildir>
Whats going on here I havent changed any dovecot or sql stuff yet. The patch isn't working for my behaviour but I hope dos will we disabled to create me folders 100drets of them for one domain.
Please help...
Best Regards,
Marcel
User & group dovecot-deliver.log
Submitted by Anonymous (not verified) on
Hi Chris,
great tutorial.
Can you update it for fixing the user/group permisions for that file, should be "vmail"?
Thanks
Maildir - wrong location
Submitted by Anonymous (not verified) on
p.s.
Submitted by Anonymous (not verified) on
p.p.s. dovecot.conf
Submitted by Anonymous (not verified) on
ISP-style Email Server with Debian-Etch and Postfix 2.3
Submitted by Anonymous (not verified) on
Hi,
I have gone thought your "ISP-style Email Server with Debian-Etch and Postfix 2.3" tutorial, I have successfully completed until Step 5. When I was restarting it successfully restarted(message appears). However, when I enter "postfix status" command it says's postfix service stopped.
Can you Help me to solved this issue?
Thanks
Chandana
Under Ubuntu 10.4, cmusieve
Submitted by Anonymous (not verified) on
Under Ubuntu 10.4, cmusieve is called sieve. If you're running Ubuntu (like I do), you have to replace "mail_plugins = cmusieve" with "mail_plugins = sieve" under the lda settings in dovecot.conf.
Will B.
Submitted by Anonymous (not verified) on
Thanks you so very much for posting this. I upgraded my server and was pulling my hair out trying to figure out why I was getting a "temporary failure" from my mail server.
/var/log/mail.log
Submitted by Anonymous (not verified) on
when i go to /var/log/mail.log
Instead off:
Ok that is normal :) But
Submitted by Anonymous (not verified) on
Ok that is normal :) But still can`t find the mailboxes
Change cumsieve in sieve
Submitted by Anonymous (not verified) on
Hi guys,
I'm reading these pages and I found a little problem in the configuration of sieve.
protocol lda { log_path = /var/vmail/dovecot-deliver.log auth_socket_path = /var/run/dovecot/auth-master postmaster_address = postmaster@example.com mail_plugins = cmusieve }At the voice "mail_plugins = cumsieve" , according with dovecot WIKI ( http://wiki.dovecot.org/LDA/Sieve),
we need to change "cumsieve" with "sieve" so the correct lines are:
protocol lda { log_path = /var/vmail/dovecot-deliver.log auth_socket_path = /var/run/dovecot/auth-master postmaster_address = postmaster@example.com mail_plugins = sieve }Pages