From Zimbra :: Wiki
Local mail delivery problem
If you don't want to configure split dns, you can use this. By default postfix performs a lookup against dns for a local (lmtp) delivery. If want to avoid configuring split dns, you can set postfix_lmtp_host_lookup to native mode. Then postfix will lookup in /etc/hosts file to deliver a local email rather than doing a dns query.
su - zimbra zmlocalconfig -e postfix_lmtp_host_lookup=native
You may need to restart zmcontrol to update the setting.
Note: This will work only on postfix 2.3 or later.
Self Signed Certificates in 5.x
Simple five steps to re-deploy the self signed certificate via command line. These steps are only for single server node. Run as ROOT.
/opt/zimbra/bin/zmcertmgr createca /opt/zimbra/bin/zmcertmgr deployca /opt/zimbra/bin/zmcertmgr createcrt -new /opt/zimbra/bin/zmcertmgr deploycrt self
If you have ZCS older than 5.0.6, then use following command to deploy the certificate.
/opt/zimbra/bin/zmcertmgr install self -new
Restart the zmcontrol.
su - zimbra zmcontrol stop zmcontrol start
Using zimbra server only as a Store with a non-zimbra MTA
Delivering emails from an non-zimbra postfix server to Zimbra on lmtp (7025) port. This is an example for domain abc.com. Zimbra server address is server.zimbra.com
1. Make sure mx for abc.com pointed to postfix sever. And it can receive emails for abc.com 2. Create abc.com domain in zimbra. 3. Add "mailbox_transport" parameter to main.cf to deliver emails to zimbra server.
mailbox_transport = lmtp:<zimbra_hostname>:7025
Save and reload postfix.
Important: User account must be created on zimbra server whom mails are sent.
That should be enough to deliver all emails to zimbra server.
Holding the Postfix Queue at time of server migration/maintenance
Holding the postfix queue at the time of migration. Specifically at the time when you need mailboxd to be running so that imapsync can inject emails.
Hold the queue:
postsuper -h ALL
Release the hold queue:
postsuper -r ALL
To delete the mails from the queue:
'cat /tmp/deletelist | /opt/zimbra/postfix/sbin/postsuper -d -'
- Other way it to create a file and define the user's whose emails you want to hold.
1.Create a stub file called /opt/zimbra/conf/migration-hold that will be used by Postfix to HOLD messages and then "postmap" this file to create the .db hash file.
2. Modify /opt/zimbra/conf/postfix_recipient_restrictions.cf to include the line in bold below.
reject_non_fqdn_recipient permit_sasl_authenticated permit_mynetworks reject_unlisted_recipient check_recipient_access hash:/opt/zimbra/conf/migration-hold permit
3. Execute "postfix reload" as the zimbra user. main.cf will now reference the new migration-hold file
4. The migration-hold file will contain the full list of email addresses that will be migrated during the impending migration in the following format:
email@example.com HOLD migration in progress firstname.lastname@example.org HOLD migration in progress
Now the MTA will accept the message, but place it in the HOLD queue as shown below:
postfix/smtpd: NOQUEUE: hold: RCPT from unknown[xx.xx.xx.xx]: <sender@domain>: Recipient address migration in progress; from=<email@example.com> to=<recepient@domain>
5. Finally, the "postsuper -H ALL" command should be executed on each Zimbra MTA to allow all held mail to be moved back into the active queue for delivery.
6. After migration has been completed, all empty migration-hold file will be removed and postfix_recipient_restrictions.cf will have the check_recipient_access line deleted.
Manually Copying ldap data from Master to Replica
These steps are for ZCS 5.x and earlier versions.
After converting the master ldap server to be a replica from the wiki http://wiki.zimbra.com/index.php?title=Promoting_Replica_to_LDAP_Master the replica server may take time to sync entire ldap data from the master server. These steps will guide you to manually copy the data from master server to the replica server. This is also useful if you have huge amount of ldap data on master and don't wish to sync the entire data through the network.
Steps to followed on the Master server:
1. Create a backup directory and take a dump of ldap data.
mkdir /backup chown zimbra:zimbra /backup /opt/zimbra/libexec/zmslapcat /backup
Steps to follow on the Replica server:
1. Create a directory on replica server and copy the ldap dump in it.
mkdir /backup chown zimbra:zimbra /backup Copy the ldap.bak from the master server's /backup directory and place it in /backup directory of this server.
2. Removing and recreating the openldap data.
cp /opt/zimbra/openldap-data/DB_CONFIG /tmp rm -rf /opt/zimbra/openldap-data/* cp /tmp/DB_CONFIG /opt/zimbra/openldap-data/ mkdir -p /opt/zimbra/openldap-data/logs /opt/zimbra/openldap-data/accesslog/db /opt/zimbra/openldap-data/accesslog/logs chown -R zimbra:zimbra /opt/zimbra/openldap-data
3. Restoring the ldap data.
/opt/zimbra/openldap/sbin/slapadd -q -b "" -f /opt/zimbra/conf/slapd.conf -cv -l /backup/ldap.bak
You may need to restart zmcontrol on the replica. Also make sure if replica is syncing with the master server by looking at /var/log/zimbra.log file.
Replacing organiser of a meeting
1. zmmailbox -z -m firstname.lastname@example.org gru /Calendar > /tmp/resourceA.ics
2. modify resourceA.ics (i.e. change the organizer from user to the new person) and rename it to, say, resourceA_updated.ics
3. zmmailbox -z -m resourceA@laika.com pru /Calendar /tmp/resourceA_updated.ics
Changing login skin and logo per domain
1. Set virtual hosts for domains which you need customize skin/logo.
su - zimbra zmprov md <domainname> zimbraVirtualHostname <domainname>
Setting zimbraVirtualHostname is very important. It is the URL which users have to connect to see the branding of the domain. It can be different from the actual domain name, and you need to set up DNS entries for the virtual hostname.
Your domain is domain1.com, and you set zimbraVirtualHostname to mail.domain1.com. You need to make sure mail.domain1.com is resolvable the the mailstore (or proxy, if using http proxy). Then users will need to connect to http://mail.domain1.com to see the branding for domain1.com.
2. Create custom skins for each domain. Or you can just place the logo banners at below mentioned paths.
3. For each domain define two attributes
zmprov md <domainname> zimbraSkinLogoLoginBanner /zimbra/skins/<skinname>/logos/LoginBanner.png zmprov md <domainname> zimbraSkinLogoAppBanner /zimbra/skins/<skinname>/logos/AppBanner.png zmprov md <domainname> zimbraSkinLogoURL http(s)://www.serverurl.com
Note: Full path of /zimbra/skins/<skinname>/logos/* is /opt/zimbra/jetty/webapps/zimbra/skins/<skinname>/logos/ But it should be defined as mentioned about without /opt/zimbra/jetty/webapps part.
4. Restart zmmailboxdctl
su - zimbra zmmailboxdctl stop zmmailboxdctl start
Changing Index Volume
By-default index volume is set to /opt/zimbra/index. Some administrators may want to change it to other directory (which may be mounted over the network). If you add a new index volume and set it as current, new index data for old users will still be saved to /opt/zimbra/index (old) volume. Only index data of new users (which are added after setting new volume) will be added to new volume. This results in two index directories. Here are the steps which will help to set new index volume keep all index data in one place regardless of old/new users.
In this example (tested on 5.0.11), old volume is /opt/zimbra/index which is default. New volume is /mnt/index and its volume ID is 3.
1. Create a new directory /mnt/index on file system. Changed permission to zimbra:zimrba. From Admin Console add new index volume and set it as current. Make sure data is been added to new volume by creating a new account and sending an email to it.
2. Note the volume ID by running this command as zimbra user.
3. Stop zimbra services. This will make sure no new messages are coming in and hence no new index data is been written.
4. Move all contents of /opt/zimbra/index to /mnt/index/
5. Start mysql server.
6. Manually update "index_volume_id" for each account to id of /mnt/index in mailbox table. You will need to run following command in loop for all user IDs.
mysql zimbra -e "update mailbox SET index_volume_id='<VolumeID>' where id=<mailboxID>"
For example. Updating index_volume_id for one account whose ID is 101.
mysql zimbra -e "update mailbox SET index_volume_id='3' where id=101"
You can find mailboxID with this command.
zmprov gmi <accountname>
7 . Stop mysql.server
8. Start zimbra services.
Note: Make sure you test above steps on a test box before doing on production server. I also recommend to make a backup copy of /opt/zimbra/index directory. If need help in above procedure, contact zimbra support.
Further Restricting Postfix Recipient
In above mentioned wiki, you can restrict who can send emails to restricted users specially distribution lists. If you want to further restrict DLs for other set of users, these are the steps. For example, you can have multiple recipient and sender lists and you can define which lists can send mail to specific recipient list. I did this using additional smtpd_restriction_classes. Please refer above wiki document to configure initial smtpd_restriction_classes. Then follow these steps:
1. Add users in this file who will be able to send further restricted DLs.
vi /opt/zimbra/postfix/conf/permitted_senders2 email@example.com OK
2. Add distribution lists in this file which you want to further restrict down.
vi /opt/zimbra/postfix/conf/protected_recipients2 firstname.lastname@example.org permitted_senders_list2
3. Create the hash files using postmap.
postmap /opt/zimbra/postfix/conf/permitted_senders2 postmap /opt/zimbra/postfix/conf/protected_recipients2
4. Modify /opt/zimbra/postfix/conf/main.cf entries to look like this (which you already configured using above mentioned wiki document).
permitted_senders_list = check_sender_access hash:/opt/zimbra/postfix/conf/permitted_senders, reject smtpd_restriction_classes = permitted_senders_list permitted_senders_list2 permitted_senders_list2 = check_sender_access hash:/opt/zimbra/postfix/conf/permitted_senders2, reject
5. Modify /opt/zimbra/conf/postfix_recipient_restrictions.cf first like entry to looks like this.
check_recipient_access hash:/opt/zimbra/postfix/conf/protected_recipients hash:/opt/zimbra/postfix/conf/protected_recipients2
6. Reload postfix.
This is an example to add one additional list. You can add multiple "permitted_senders"/"protected_recipients" files and set the option accordingly.
Enabling Amavisd Debug Logging
Steps to enable message trace debug logging for amavisd. Edit following line from /opt/zimbra/conf/amavisd.conf.in file. The verbosity value can be changed from 0..5. 1 is the minimum for msg tracing.
$log_level = 1
Spamassassin debug logging can be enabled. Un-comment following line from /opt/zimbra/conf/amavisd.conf.in file.
# $sa_debug = 1;
Simple script to send mass emails
To send mass emails to a recipient. Just save it to a file and run it. You can run it via crontab to send constant emails. Or run in a loop to send emails to bunch of users. Make sure smtp server address is configured in your system's /etc/mail.rc file. Syntax to set mail server is:
#!/bin/bash # Script to mass send emails RCPT=$1 COUNT=$2 if [ -z $RCPT ] || [ -z $COUNT ] then echo -e "\nUsage: $0 <RECIPIENT ADDRESS> <NO OF TEST EMAILS>" exit fi LIMIT=0 until test $LIMIT = $COUNT do echo "This is a test email no $LIMIT" | mail -s "Test email # $LIMIT" $RCPT LIMIT=`expr $LIMIT + 1` done
Configure outgoing IP address for email
If your server have more than one IP address/NIC cards, then postfix will use all IP addresses randomly to send out emails. If one of the IP address is blacklisted or due to SPR record issue, you want to send out all outgoing emails through one IP only, use these steps.
postconf -e smtp_bind_address="XXX.XXX.XXX.XXX" zmmtactl restart
You also need to modify amavisd configuration so that amavisd can accept emails from that specific IP address. Add following line at end of /opt/zimbra/conf/amavisd.conf.in file. You can add as many IPs required.
@inet_acl = qw( 127.0.0.1 XXX.XXX.XXX.XXX [::1] ),
Save the file and restart zmamavisdctl.
Please note this changes may not survive zimbra upgrades.