Talk:Virtual user mail system with Postfix, Dovecot and Roundcube
crt file
Dovecot configuration suggests setting the certs 0444 for the .crt and 0400 for the .key, but the wiki suggests 0644 and 0600, respectively. Personally, I do not see why anyone should have write permissions on the certs, esp. since they're not meant to be modified. Suggestions? --Gesh (talk) 23:30, 9 August 2012 (UTC)
Hmm... I think you are right Gesh. I can't fathom how making the certs read only could damage the setup. --Justforgetme (talk) 00:10, 10 August 2012 (UTC)
Also, shouldn't the chown nobody:nobody also be executed on the .crt file? I cannot understand the rationale of having it owned by root. At least with system-configuration files, you'd want both that root will be able to edit them and that *only* root be able to edit them. --Gesh (talk) 01:35, 10 August 2012 (UTC)
Yeah there probably isn't anything wrong with making them read-only. --Svenstaro (talk) 00:23, 12 August 2012 (UTC)
- I have changed this article so the permissions are exactly the same as in the Dovecot manual. Before my edits, the
.key
was owned by "nobody", which not safe at all, since anybody logged in as "nobody"(=loads of potentially unsafe daemons) can read the.key
. Who owns the.crt
does not matter, so it's easiest to keep it root. --Lonaowna (talk) 12:44, 16 June 2014 (UTC)
Problem with dovecot and roundcube
Hey there! Excellent tutorial, it almost worked like a charm! I had some problems with dovecot and roundcube. I'm not sure if they are sufficiently general to be added on the main tutorial, but I wanted to discuss them here:
- Dovecot Greeting. I had to place a Dovecot greeting in /etc/dovecot/dovecot.conf. I included "login_greeting = Dovecot ready for action."
- Instead of using TLS for IMAP in Roundcube I had to configure SSL. In particular, I had to change this "$rcmail_config['default_host'] = 'ssl://localhost/';" on Roundcube main.inc.php.
- I missed a comment on the 'username_domain' option in the configuration. As it was not mentioned in the tutorial I wrongly assumed that Dovecot allows login with only the username. But then I couldn't login from Roundcube using my username. Adding the "$rcmail_config['username_domain'] = 'mydomain.net';" option in Roundcube main.inc.php.
Thanks for the tutorial, I think it is pretty straightforward for a complex task a setting up the mail server. Best regards! --Es0x279e (talk) 10:12, 6 October 2012 (UTC)
Hi! I cannot for the life of me get roundcube to work. It fails when I try to do the login to the IMAP server during installation. I get: "Connecting to tls://localhost/... IMAP connect: NOT OK(Login failed for [edited] from [edited]. Empty startup greeting (localhost:993))" I've tried changing it to ssl:// and without ssl:// or tls:// but for some reason it just does not work and I do not know where to go from here. Help would be greatly greatly appreciated. --Pei (talk) 04:20, 2 November 2012 (UTC)
Undid the last contribution of (Mehtab) because listening interfaces should beimplementation speciffic for this Postfix installation. If anybody disagrees let me know. Justforgetme (talk) 06:41, 4 December 2012 (UTC)
Expanded the Roundcube section and added some info for SpamAssassin and added the tip to remove "Received header". Had to do a bit of digging today to set it up, figured I add it here so it will be helpful. KingX (talk) 02:55, 21 April 2013 (UTC)
Thank you!, the best tutorial I found, just want to point out some problems I had during the installation.
A) If vmail id/gid != 5000, you may have dovecot-sql.conf correct, but postfix still complains for db access. Better listen to Svenstaro from the begining.
B) Roundcube installer: DO NOT TRUST IT!.
main.inc.php ,
$rcmail_config['default_host'] = 'ssl://localhost';
If you use tls for IMAP, it will not work and you will get nightmares with the "STARTTLS command first" error. (roundcube tries to use ssl anyway)
You can use tls for the SMTP server thoug, but also keep the next lines like this:
$rcmail_config['smtp_server'] = 'tls://localhost'; $rcmail_config['smtp_port'] = 587; $rcmail_config['smtp_user'] = '%u'; $rcmail_config['smtp_pass'] = '%p';
If you use ssl, you also have to allow ssl connections. Change 'encrypt' for 'may' in your master.cf file, or you will have those nightmares again:
-o smtpd_tls_security_level=encrypt
C) mysql.so and imap.so must be enabled (/etc/php/php.ini)
D) php.conf: You can create aliases for roundcube and postfixAdmin folders, so you don't bulk your /srv/http/ directory
E) Your hostname have to include your domain name:
lupus@ulula:~$ hostname myHostName.mysite.org
F) Bloking port 25 is a common practice for ISP's. This port is where all incoming mail is delivered, so you will not be able get your mail from the outside world. Don't panic (I did), you need a MX DNS server with port fordwarding (or convice your isp that blocking the smtp port is for loosers). This site offers the service for free, good enough to play around: [1]
Edit your master.cf file to something like this
smtp inet n - n - - smtpd 26 inet n - n - - smtpd submission inet n - n - - smtpd
Last word of advice: DO NOT mix virtual server mail with non virtual server mail configuration! --dcgasca (talk) 04:43, 22 June 2013 (UTC)
Server refuses connection
Hello! Whenever I try to login to the mailaccount I created using postfixadmin with roundcube, I get the following error message (from roundcube):
IMAP Error: Login failed for me@my.domain.com from my.ip.adre.ss. Could not connect to ssl://localhost:993: Connection refused in /usr/share/webapps/roundcubemail/program/lib/Roundcube/rcube_imap.php on line 184 (POST /roundcubemail/?_task=login&_action=login)
Also, when I tried to send an email to my account from another E-Mail adress, I got the following error report:
The recipient server did not accept our requests to connect. Learn more at http://support.google.com/mail/bin/answer.py?answer=7720 [(0) my.domain.com. [81.10.164.94]:25: Connection refused]
Whats wrong?
relay_domains = * might me a bad idear
I included the following warning into the article. I am not 100% sure about this. So maybe someone should check it and let us discuss it here.
relay_domains = *
might me a bad idear (see http://www.postfix.org/BASIC_CONFIGURATION_README.html#relay_to). You usually do not want postfix to forward mail from strangers.--PMay (talk) 14:15, 9 January 2014 (UTC)
Yes, doing it this way sets up your server as an open relay, which is a Very Bad Idea. Most setups like these specify another mysql proxy that can get the domains allowed to relay -
main.cf:
relay_domains = $mydestination, proxy:mysql:/etc/postfix/relay_domains_maps.cf
relay_domains_maps.cf:
user = postfix_user password = hunter2 hosts = localhost dbname = postfix_db query = SELECT domain FROM domain WHERE domain='%s' and transport = 'relay' and active = 1 AND NOT exists (select * from alias_domain where alias_domain = '%s' AND alias_domain.active = '1')
Maleckii (talk) 23:42, 24 January 2014 (UTC)
I'm going to change the default value from * to what was suggested above. I don't think it's a good idea to have * as a default. Simonsmiley (talk) 16:44, 16 June 2015 (UTC)
Postfix Database
I followed this guide and found that my setup would work on the surface (I could even go in to Roundcube and believe I was sending mail but, the logs always have a lookup failure) but found that after letting postfixadmin set up the database, the mappings don't bind to anything in particular. For example, within "virtual_mailbox_domains" a table called forwardings is specified but this table does not exist.
This is due to the way PostfixAdmin will set up the Database schema; I have since edited the wiki as the little note quite simply doesn't exist.
Virtual_Alias_Maps.cf for non-PostfixAdmin configurations appears to be incorrect
I may be missing something, but as far as I can tell, the suggested value of "select_field = virtual" for /etc/postfix/virtual_alias_maps.cf is incorrect when users are setting up without PostfixAdmin. The msyql db structure the user is instructed to create earlier on does not have a "virtual" column in the 'domain' table, and in practice, following though with this tutorial results in me seeing the errors:
Oct 05 18:09:59 (myserver) postfix/proxymap[706]: warning: mysql query failed: Unknown column 'virtual' in 'field list' Oct 05 18:09:59 (myserver) postfix/trivial-rewrite[708]: warning: proxy:mysql:/etc/postfix/virtual_alias_maps.cf: table lookup problem Oct 05 18:09:59 (myserver) postfix/trivial-rewrite[708]: warning: virtual_alias_domains lookup failure
in my log. Changing the 'select_field' entry in that file to 'domain' appears to fix the problem, and seems to match up with the DB structure the reader is told to create. So, the suggested /etc/postfix/virtual_alias_maps.cf for users not using PostfixAdmin should more likely be something like:
user = postfix_user password = hunter2 hosts = localhost dbname = postfix_db table = domains select_field = domain where_field = domain
I'm suggesting this rather than editing it because I'd rather someone more familiar with the setup of postfix and sql take a look before making the change. Thanks!
Tutorial does not create additional folders (Trash/Drafts)
When I follow this tutorial no additional user folders (Trash/Drafts etc) are created.
Users cannot delete emails or save drafts. A delete request in Roundcube generates the following: "Server Error: UID MOVE: Internal error occurred. Refer to server log for more information. [2015-11-03 06:59:11] (0.000 + 0.000 secs)."
Can anybody explain how to get these folders working so that the Wiki can be amended?
Update: Fixed this with the following additions to the Roundcube config file - will amend the wiki:
$rcmail_config['default_imap_folders'] = array('INBOX', 'Drafts', 'Sent', 'Junk', 'Trash'); $rcmail_config['create_default_folders'] = true; $rcmail_config['protect_default_folders'] = true;
Is there a reason why this does not follow the recommendations in the postfixadmin documentation (the *.cf files etc... sql subdirectory for easy chmodding...)? I'm not sure how/if the non-postfixadmin setup works and can't tell if changing the configuration to resemble postfixadmin defaults more closely would break something there... but domain catchalls etc definitely doesn't work with (only) the config from this wiki page. Whoops (talk) 15:29, 16 December 2016 (UTC)
The tutorial does not use Dovecot for email delivery
This is an interesting thing I came across when trying to add Sieve and SpamAssassin to my virtual mail setup that I created using this guide. The guide configures Postfix to do the delivery directly instead of making Dovecot do it, which makes it impossible to use Sieve with SpamAssassin through Dovecot. I'd suggest that this is corrected - possibly even explaining both lmtp and lda. Currently - unfortunately - even the guide in Dovecot documentation is better than this.
Oh and I also don't get why the configuration placing and such is so messed up, or why the dovecot/conf.d directory isn't used.
--Amunak (talk) 13:19, 8 September 2018 (UTC)
- I also had difficulty getting spamassassin to work while following the guide. Instead of trying to figure it out, I opted instead this go around to use rspamd. Amunak, if you know how to get SpamAssassin to work, please correct the guide, or at the least add a note pointing to the link you mentioned. I might add a note in the guide that other spam scan options, such as rspamd, exist...
- Regarding why the configuration is so messed up, that's how dovecot was configured a few years ago. I remember using this same guide back around 2012, and since then Dovecot changed. However, the guide still works, since the new configuration locations are an attempt to not have one huge configuration file, but a bunch of small ones to make it easier. As people edited and updated the guide, nobody redid it to take into account the new format. Personally, I like having one file where all the configurations are located instead of scattered throughout multiple files. That being said, I would have no problem someone reparsing the information to the new format.
- Lastly, I'm happy the guide does exist. I know there's that big tag at the top that mentions this is a candidate for merging with Postfix, but setting up an email server with virtual users is not a trivial task. This guide ties in a lot of moving pieces and, for the most part, shows you how to get them to work together. Cheers! :--Brasas (talk) 19:57, 9 September 2018 (UTC)
Section 'Setting up Postfix' might include potentially detrimental values
Section 8 'Setting up Postfix' includes following settings.
local_transport = virtual local_recipient_maps = $virtual_mailbox_maps
Please help me understand the reason behind this. The guide attempts to set up virtual mail accounts. Why are settings touched that affect local delivery? In my understanding, the first line instructs Postfix to deliver local mail with the virtual domain mail delivery agent. The second line provides the virtual mailbox maps to look up the local users. Is this necessary or even useful? At no point in the guide are local users added to 'mailbox' (the table that gets queried). The guide doesn't address mixing local users and virtual users. Therefore, shouldn't following this guide lead to delivery errors whenever local users are getting mails and do not turn up in 'mailbox'? SomeOwl (talk) 16:36, 12 March 2019 (UTC)
- I second this observation. Overriding local transport especially interferes when additional software like mailing lists. I spend multiple hours debugging my Mailman setup, as did other persons reading this Wiki Tzwenn (talk) 13:33, 15 April 2019 (UTC)
'candidate for merging with Postfix': Please no
I need this as a separate tutorial. When I used Ubuntu (before my conversion experience) I used this tutorial: A Mailserver on Ubuntu 16.04: Postfix, Dovecot, MySQL. I find that the separate tutorial here on Arch provides a should-be complete guide to integrating these various web apps together on a single mail server. Even if the Arch Wiki gurus decide these should be merged in order to maintain organizing standards, please at least included a comparable guide. We idiots need this to be less of a nuisance to the Arch community.