Zimbra Mail Serve Configuration and Administration
We already have our Zimbra working, but with the basic installation we did not get it to be as professional as our title pretends it to be
Therefore, we are going to make a series of configurations, not only at the Zimbra level, that will help us to achieve this purpose, so let's go for it.
Black Lists (RBL)
Blacklisting is an attempt to stop spam in the jungle that is the internet today. Basically its operation is to make a list of IPs that are marked as spammers due to different criteria. For the configuration we will go to the administration console of our Zimbra server, going through the web browser to the address https://[SERVER]:7071 , where SERVER is the IP or DNS resolution of our server
In our Zimbra administration section we will go to Configure → General Settings →MTA and here we will go down to the DNS Checks section , where we will add the following blacklists for each of the sections we see.
RBL list :
Zimbra Primary DNS Modification
As you may remember, in the first post we used a temporary DNS server for the installation. Since it is temporary, we need to remove it from the Zimbra configuration and add a real Primary DNS. To check the primary DNS you use:
So we have to modify it to use a real, production server. Let's use Google's:
SPF
For communication between mail servers, the use of SPF is very common . What this system does is take into account the DNS records of our domain to ensure that the sender of an email is authorized to do so .
That is, if someone tries to send an email using our irontec.com domain, the receiving mail server should check whether the sender is allowed to send emails on our behalf. In case the sender is not authorized, the receiving server should reject the mail since it is not authorized to send mails on our behalf .
To carry out this configuration we must create a new record of type TXT in our DNS server . Normally we will have the DNS server in a provider that will facilitate this task through a control panel.
The TXT record format should be:
Therefore, we are going to make a series of configurations, not only at the Zimbra level, that will help us to achieve this purpose, so let's go for it.
Black Lists (RBL)
Blacklisting is an attempt to stop spam in the jungle that is the internet today. Basically its operation is to make a list of IPs that are marked as spammers due to different criteria. For the configuration we will go to the administration console of our Zimbra server, going through the web browser to the address https://[SERVER]:7071 , where SERVER is the IP or DNS resolution of our server
In our Zimbra administration section we will go to Configure → General Settings →MTA and here we will go down to the DNS Checks section , where we will add the following blacklists for each of the sections we see.
RBL list :
- zen.spamhaus.org
- bl.spamcop.net
- psbl.surriel.com
- dbl.spamhaus.org
- multi.surbl.org
- multi.surbl.org
Zimbra Primary DNS Modification
As you may remember, in the first post we used a temporary DNS server for the installation. Since it is temporary, we need to remove it from the Zimbra configuration and add a real Primary DNS. To check the primary DNS you use:
zimbra@mail:~$ zmprov gs `zmhostname` zimbraDNSMasterIP
# name mail.itinfs.com
zimbraDNSMasterIP: 192.168.90.1
So we have to modify it to use a real, production server. Let's use Google's:
zimbra@mail:~$ zmprov ms `zmhostname` -zimbraDNSMasterIP 192.168.90.1
zimbra@mail:~$ zmprov ms `zmhostname` +zimbraDNSMasterIP 8.8.8.8
zimbra@mail:~$ zmprov gs `zmhostname` zimbraDNSMasterIP
# name mail.itinfs.com
zimbraDNSMasterIP: 8.8.8.8SPF
For communication between mail servers, the use of SPF is very common . What this system does is take into account the DNS records of our domain to ensure that the sender of an email is authorized to do so .
That is, if someone tries to send an email using our irontec.com domain, the receiving mail server should check whether the sender is allowed to send emails on our behalf. In case the sender is not authorized, the receiving server should reject the mail since it is not authorized to send mails on our behalf .
To carry out this configuration we must create a new record of type TXT in our DNS server . Normally we will have the DNS server in a provider that will facilitate this task through a control panel.
The TXT record format should be:
v=spf1 a mx a:www2.itinfs.com ip4:123.4.5.6 -allThe explanation of the format is simple, first we indicate v=spf1 to indicate that it is an SPF record, and then who is authorized to send mails in which it is configured. In the case of this example:
v=spf1: Indicates that the TXT record is for SPF checking
a: indicates that the server with record A is authorized
mx: indicates that the server with MX record of our domain irontec.com is also authorized
a:www2.itinfs.com : The server whose IP matches the A record of the domain www2.itinfs.com is authorized
ip4:123.4.5.6 : The server with IP 123.4.5.6 is authorized
-all: As you can see in the following table, with this we indicate that the rest of the servers are not authorized unless they coincide with the previous rules
Parameter Result Meaning
+all pass Allows all mails, as if there was nothing configured ( Not recommended )
-all fail All servers that do not match the above rules are not allowed to send mail.
~all soft fail It allows sending mails, but if something goes wrong it will be marked as “softfail”.
DKIM
The DKIM (DomainKeys Identified Mail) method is used to associate the domain name and the email, allowing a person to assume responsibility for an email.
Basically what the DKIM system does is that the sending server signs the outgoing mails , and the receiving mail server performs a DNS check to ensure that the signed mail is valid against the public key added as a DNS record.
To do this, from the console of our Zimbra server we will execute, as the zimbra user, the following command:
v=spf1: Indicates that the TXT record is for SPF checking
a: indicates that the server with record A is authorized
mx: indicates that the server with MX record of our domain irontec.com is also authorized
a:www2.itinfs.com : The server whose IP matches the A record of the domain www2.itinfs.com is authorized
ip4:123.4.5.6 : The server with IP 123.4.5.6 is authorized
-all: As you can see in the following table, with this we indicate that the rest of the servers are not authorized unless they coincide with the previous rules
Parameter Result Meaning
+all pass Allows all mails, as if there was nothing configured ( Not recommended )
-all fail All servers that do not match the above rules are not allowed to send mail.
~all soft fail It allows sending mails, but if something goes wrong it will be marked as “softfail”.
DKIM
The DKIM (DomainKeys Identified Mail) method is used to associate the domain name and the email, allowing a person to assume responsibility for an email.
Basically what the DKIM system does is that the sending server signs the outgoing mails , and the receiving mail server performs a DNS check to ensure that the signed mail is valid against the public key added as a DNS record.
To do this, from the console of our Zimbra server we will execute, as the zimbra user, the following command:
root@mail:~# su - zimbra
zimbra@mail:~$ /opt/zimbra/libexec/zmdkimkeyutil -a -d itinfs.com
DKIM Data added to LDAP for domain itinfs.com with selector 0F12345-C5DB-35E1-134A- 7EEE12C2BA47
Public signature to enter into DNS:
0F12345-C5DB-35E1-134A-7EEE12C2BA47._domainkey IN TXT ( "v = DKIM1; k = rsa;"
"p = M1234567890GC123456789Ib3DQEBAQU123456789BiQKBgQCyyhoer123456789ts4 / oj064WpCi + wPo0gvWwhS12345678927yAbHy9 + V3gt123456789jOBz123456789m0DE1jheVY3KqB4u / OGU123456789d4tid123456789YeJKQhSbLFjZe / IZq123456789XDNLLEQIDAQAB"); ----- DKIM key 0F12345-C5DB-35E1-134A-7EEE12C2BA47 for itinfs.comWe have already generated the key, and what we have obtained as a result of the command is the public key that we will now have to add in our DNS. If you look at the output of the command, it says "Public signature to enter into DNS", that is, we have to create a record of type TXT, such as a domain that is 0F12345-C5DB-35E1-134A-7EEE12C2BA47._domainkey.itinfs.com and that the value it contains is what the command has given us:
Limit internal LDAP size
Zimbra makes use of an internal LDAP server for information storage, but by default it is configured so that its storage reaches up to 80GB. Let's limit it so it's not so much, stopping zimbra first:
v=DKIM1; k=rsa; p = M1234567890GC123456789Ib3DQEBAQU123456789BiQKBgQCyyhoer123456789ts4 / oj064WpCi + wPo0gvWwhS12345678927yAbHy9 + V3gt123456789jOBz123456789m0DE1jheVY3KqB4u / OGU123456789d4tid123456789YeJKQhSbLFjZe / IZq123456789XDNLLEQIDAQABLimit internal LDAP size
Zimbra makes use of an internal LDAP server for information storage, but by default it is configured so that its storage reaches up to 80GB. Let's limit it so it's not so much, stopping zimbra first:
root@mail:# su - zimbra
zimbra@mail:~$ zmcontrol stop
Host mail.itinfs.com
Stopping vmware-ha...skipped.
[...]
zimbra@mail:~$ zmlocalconfig -e ldap_db_maxsize=67108864
zimbra@mail:~$ zmlocalconfig -e ldap_accesslog_maxsize=536870912
zimbra@mail:~$ zmcontrol start
Host mail.itinfs.com
Starting ldap...Done.
[...]SSL certificate
I am not going to delve into this section, since in this blog we have already talked about what are really secure SSL certificates (SHA-2) and how to create them for Zimbra . Therefore I use this section as a reminder so that you do not forget to generate your certificate and install it in Zimbra.
Apart from the generation of the certificate, in order for our installation to have the highest security score in the SSL Labs test , we have to make a small modification to our Zimbra installation. We will execute:
Now we need to edit the files
I am not going to delve into this section, since in this blog we have already talked about what are really secure SSL certificates (SHA-2) and how to create them for Zimbra . Therefore I use this section as a reminder so that you do not forget to generate your certificate and install it in Zimbra.
Apart from the generation of the certificate, in order for our installation to have the highest security score in the SSL Labs test , we have to make a small modification to our Zimbra installation. We will execute:
root@mail:~# cd /opt/zimbra/conf
root@mail:/opt/zimbra/conf# openssl dhparam -out dhparams.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[...]
root@mail:/opt/zimbra/conf# chown zimbra:zimbra dhparams.pemNow we need to edit the files
/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.templateand
/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.template( we will have to modify the write permissions), and we make sure that the following 4 new lines appear:
server
{
[...]
ssl_dhparam /opt/zimbra/conf/dhparams.pem;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 5m;
include ${core.includes}/${core.cprefix}.web.https.mode-${web.mailmode};
[...]And finally, we will modify the types of encryption that our server will use to communicate through the web browser:
zimbra@mail:~$ zmprov mcf zimbraReverseProxySSLCiphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE- ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA- AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128: AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4'
zimbra@mail:~$ zmproxyctl restart
Stopping nginx...done.
Starting nginx...done.Extra settings
In this section we are going to explain certain extra configurations, which although they are not necessary, we will probably make them at some point, and it is always good to take them into account.
Attachment size
Zimbra by default limits the size of attachments to 10000KB , which in some cases can be a bit limited. If we want to modify this size we must go to Configure → General Settings →MTA and modify the section "Maximum message size". When modifying this size, we must also modify the “Maximum size of a file uploaded from the desktop” whose directive is found in Configure → General Settings → General Information
Class of service
Class of Service , or COS from now on, is a simple way to easily configure features to accounts. As an example, if we want to limit several accounts so that the size of their mailbox is 1GB (instead of unlimited), we can create a new COS called limited and in the advanced section modify the option "storage space available for the account ( MB)" and limit it to 1024.
We can edit the accounts and modify their "Account Settings"
Of course, limiting the size of the mailbox is only a sample of what can be done. We can limit so that there is no POP access, that the account cannot have a briefcase, access to certain zimlets...
Conclusion
After these steps we can already say that we have a professional email system using Zimbra , which can be put into production and used by our users. Keep in mind that there are many more configuration possibilities, and that these should be the minimum to take into account. We will be updating this post with extra configurations and improvements from time to time.
In this section we are going to explain certain extra configurations, which although they are not necessary, we will probably make them at some point, and it is always good to take them into account.
Attachment size
Zimbra by default limits the size of attachments to 10000KB , which in some cases can be a bit limited. If we want to modify this size we must go to Configure → General Settings →MTA and modify the section "Maximum message size". When modifying this size, we must also modify the “Maximum size of a file uploaded from the desktop” whose directive is found in Configure → General Settings → General Information
Class of service
Class of Service , or COS from now on, is a simple way to easily configure features to accounts. As an example, if we want to limit several accounts so that the size of their mailbox is 1GB (instead of unlimited), we can create a new COS called limited and in the advanced section modify the option "storage space available for the account ( MB)" and limit it to 1024.
We can edit the accounts and modify their "Account Settings"
Of course, limiting the size of the mailbox is only a sample of what can be done. We can limit so that there is no POP access, that the account cannot have a briefcase, access to certain zimlets...
Conclusion
After these steps we can already say that we have a professional email system using Zimbra , which can be put into production and used by our users. Keep in mind that there are many more configuration possibilities, and that these should be the minimum to take into account. We will be updating this post with extra configurations and improvements from time to time.
Post a Comment