Below are the Main setup before Installing the Zimbra 8.6.0
Step 1:
yum remove postfix
Step 2:
system-config-network
Step 3:
netstat -apn |grep 25
Step 4:
yum install libstdc++.so.6
Step 5:
Vi /etc/sudoers
Serch for: Defaults requiretty
And below that add
Defaults:%zimbra ! requiretty
Defaults:zimbra ! requiretty
Step 6:
chmod 0440 /etc/sudoers
Step 7:
Reboot
Step 8:
Yum install nc
Step 9:
Vi /etc/sysconfig/network NETWORKING=Yes NETWORKING IPV6=No HOST NAME=mail.it-field.net
Step 10:
Vi /etc/hosts 127.0.0.1 localhost.localdomain localhost 192.168.xx.xx mail.xxxx.xxxx
Step 11:
yum install –y sysstat perl sudo sqlite
Step 12:
yum install perl-core
Step 13:
./install.sh --platform-override
yum -y install libstdc++.so.6
After Installation of Zimbra install Zextras suite and follow the below step.
As ROOT, unpack the file you just downloaded inside a directory (we suggest in /root/) in your Zimbra server.
Enter the directory created by the unpacking of the file.
Run the install.sh script with the “all” option (so ./install.sh all).
1. Default Domain Settings
zmprov mcf ZimbraDefaultDomainName *****.com Home----Configuration------Global Settings------Default domain
2. mysql.server is not running lsof-i TCP: 25
/opt/zimbra/libexec/zmmyinit
3. Zimbra mta postfix not running
service postfix status service postfix stop
4. Mailbox stopped zmmailboxdctl is not running
service httpd status service httpd stop
sudo su-zimbra /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/commercial.crt /tmp/commercial_ca.crt /opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/commercial_ca.crt /opt/zimbra/bin/zmcertmgr viewdeployedcrt
/opt/zimbra/libexec/zmfixperms -verbose
Checking for port conflicts
Port conflict detected: 53 (zimbra-dnscache) Port conflict detected: 25 (zimbra-mta) Port conflict detected: 25 (zimbra-mta) Port conflicts detected! - Press Enter/Return key to continue
systemctl stop postfix systemctl disable postfix yum remove postfix
DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit. The organization is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for further handling, such as delivery. Technically DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication. Link
Configuring ZCS for DKIM signing
Starting with Zimbra 8.0, the ability to add DKIM signing to outgoing mail is available. Signing is done at the domain level, including alias domains. Setting up signing consists of two steps:
1. Running zmdkimkeyutil to generate the DKIM keys and selector. The generated data is stored in the LDAP server as part of the domain LDAP entry.
2. Updating the DNS server with the public DNS entry
The zmdkimkeyutil utility
The zmdkimkeyutil script allows you to do the following:
1. Add DKIM data to a domain that does not currently have DKIM enabled
2. Update DKIM data for a domain that already has DKIM enabled
3. Query the DKIM data for a domain
4. Remove the DKIM data for a domain
The domain “example.com” will be used throughout this wiki. Substitute it with your domain.
Adding DKIM data to a domain with no existing DKIM configuration
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com
After the data is generated, the public DNS record data that must be added for the domain to your DNS server will be displayed:
zimbra@example.com:~$ /opt/zimbra/libexec/zmdkimkeyutil -a -d example.com DKIM Data added to LDAP for domain example.com with selector 0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB Public key to enter into DNS: 0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB._domainkey IN TXT “v=DKIM1;=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDY5CBg15nZ2vYnRmrNub6Jn6ghQ2DXQbQgOJ/E5IGziUYEuE2OnxkBm1h3jived21uHjpNy0naOZjLj0xLyyjclVy1chrhSbsGAhe8HLXUsdXyfRvNTq8NWLsUnMEsoomtJCJ /6LYWYU1whOQ9oKZVAwWHSovAWZpByqNMZmFg7QIDAQAB” ; —– DKIM 0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB for example.com
Updating DKIM data for a domain
/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com
Whenthe DKIM keys are updated, the DNS server will need to be reloaded with the new TXT record. It is advised to leave the previous TXT record in DNS for a period of time to allow verification of emails that were signed with the previous key to continue to succeed.
Removing DKIM data for a domain
/opt/zimbra/libexec/zmdkimkeyutil -r -d example.com
This command deletes the DKIM data from LDAP. New emails will no longer be signed for the domain. The DNS TXT record should remain for a period of time to allow verification of emails signed with this key.
Retrieving the stored DKIM data for a domain
/opt/zimbra/libexec/zmdkimkeyutil -q -d example.com
This command will output all the stored DKIM information, specifically
DKIM Domain
DKIM Selector
DKIM Private Key
DKIM Public Signature
DKIM Identity
Updating DNS
1. The public key DNS record should appear as a TXT resource record at:
SELECTOR._domainkey.DOMAIN The Selector is the first portion of the output from zmdkimkeyutil In the above example, it is 0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB
1.1. Once you have added the record to your nameserver, reload DNS. 1.2. Verify that the DNS server is returning the DNS record.
dig -t txt SELECTOR._domainkey.DOMAIN NAMESERVER Example: dig -t txt 0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB._domainkey.example.com ns.example.com
2. If the key is retrieved correctly, then use /opt/zimbra/opendkim/sbin/opendkim-testkey to verify that the public key matches the private key.
/opt/zimbra/opendkim/sbin/opendkim-testkey -d example.com -s 0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB -x /opt/zimbra/conf/opendkim.conf
Revoking a DKIM key in DNS
If it becomes necessary to revoke a DKIM signing key, this can be easily done in DNS by using an empty “p=” tag in the TXT record.
Note: Before changing the content of your Postfix configuration file, make a backup of the original /opt/zimbra/postfix/conf/main.cf file in case you need to restore your configuration. Be sure to also keep a backup of your changed Postfix configuration file, in order to restore your configuration after upgrading or reinstalling.
Reconfiguring the Postfix Queue Lifetime
The default queue lifetime is 5 days. After 5 days, messages in the deferred queue are returned to the sender with an “undelivered” notice. To change the queue lifetime, use the following steps.
To reconfigure the queue lifetime
1. Log in as root in the command line utility. Switch to the zimbra user account.
su - zimbra
2. Type the following command, replacing [time] with the new queue lifetime. Time can be in seconds (s), minutes (m), hours (h), days (d), and weeks (w).
postconf -e maximal_queue_lifetime=[time]
Note: Since most Postfix daemons are short-lived, your new settings are actually recognized automatically as those daemons expire and new ones are launched. However, longer running daemons such as pickup, qmgr, and possibly trivial-rewrite will not detect changes to main.cf, so changes to parameters used by these daemons require that you reload Postfix. Changes to master.cf always require a reload. Note that with changes to the inet_interfaces parameter, a reload is not sufficient. You must stop and then start Postfix in this case. For example, to reconfigure the queue lifetime to 15 minutes, you would type:
postconf –e maximal_queue_lifetime=15m
The queue lifetime is now reconfigured.
3. To ensure that your changes are not overwritten by a future Zimbra upgrade, you can set them in the local config.
zmlocalconfig -e postfix_maximal_queue_lifetime=[time]
Some administrators prefer to more tightly control the way mail in the deferred queue is handled. Three parameters determine how the mail in the deferred queue is handled by the queue manager: queue_run_delay, minimal_backoff_time, and maximal_backoff_time.
queue_run_delay determines the time between deferred queue scans by the queue manager. The default is 1,000 seconds (1000s). This time should be less than or equal to the minimal_backoff_time setting.
minimal_backoff_time determines the minimal time between attempts to deliver a deferred message. When a message is first placed in the deferred queue, the value of this setting is what determines when the first attempt to redeliver the message is made. The default is 1,000 seconds (1000s). This time should be equal to or greater than the queue_run_delay setting.
maximal_backoff_time determines the maximal time between attempts to deliver a message. The time between each attempt to deliver a deferred message will grow exponentially until it reaches the value in this setting. The attempted deliveries are repeated at this value until the queue lifetime is reached. The default is 4,000 seconds (4000s).
To reconfigure a deferred queue parameter
1. Log in as root in the command line utility. Switch to the zimbra user account.
su - zimbra
2. Type the following command, replacing [parameter] with the parameter you want to reconfigure and replacing [time] with the new time. Time can be in seconds (s), minutes (m), hours (h), days (d), and weeks (w).
postconf -e [parameter]=[time]
To reconfigure multiple parameters, use this command for each parameter you want to reconfigure.
For example, to change the queue_run_delay parameter to 2,000 seconds and the minimal_backoff_time parameter to 2,000 seconds:
postconf –e queue_run_delay=2000s postconf –e minimal_backoff_time=2000s
The deferred queue parameters are now reconfigured. The changes will take effect immediately.
3. To ensure that your changes are not overwritten by a future Zimbra upgrade, you can set them in the local config.
zmlocalconfig -e postfix_queue_run_delay=<new value> zmlocalconfig -e postfix_minimal_backoff_time=<new value>
Any Postfix settings you change can be preserved across upgrades by creating a local config entry named postfix_<postfix key> and setting its value. This will not immediately update the value in Postfix, but will ensure that it is rewritten at the time of the next upgrade.