Difference between revisions of "Zimbra"

Jump to navigation Jump to search
597 bytes added ,  09:05, 30 January 2012
→‎Installation: Added some additional notes
(Added "Account Export Incomplete")
(→‎Installation: Added some additional notes)
Line 1: Line 1:
== Installation ==
== Installation ==
The notes below are for the situation of installing a Zimbra server in a split-DNS scenario.  Split DNS is required where you have a Zimbra server on an internal (private address range) network.  Zimbra needs to be able to resolve its own MX DNS record, therefore if your server is known publicly by one IP address, but in fact has an internal address (and the public IP is NAT'ed to the internal IP) you'll need to use split DNS.  The method below uses a DNS server installed locally on the Zimbra server, however you can also use a DNS server on your local network, if you have one available.
=== DNS Records ===
=== DNS Records ===
Firstly, you need to own a public domain name, then get your ISP to create two DNS records...
Firstly, you need to own a public domain name, then get your ISP to create two DNS records...
Line 7: Line 9:
# '''A record''' - Standard DNS record
# '''A record''' - Standard DNS record
#* EG <code> mail.sandfordit.com [A] -> 158.25.34.124 </code>
#* EG <code> mail.sandfordit.com [A] -> 158.25.34.124 </code>
#* <code> 158.25.34.124 </code> is the static IP address assigned by your ISP.  You'll need to set-up a NAT on your router (often oddly called a virtual server in domestic routers) to map incoming mail on TCP 25 to your email server's actual address (EG <code> 158.25.34.124:25 -> 192.168.1.150:25 </code>.
#* <code> 158.25.34.124 </code> is the static IP address assigned by your ISP.  You'll need to set-up a NAT on your router (often oddly called a virtual server in domestic routers) to map incoming mail on TCP 25 to your email server's actual address (EG <code> 158.25.34.124:25 -> 192.168.1.150:25 </code>).


Note, instead of an A record you can use a CNAME record if you prefer, though obviously the CNAME record will still need to point to a valid A record.  Using a CNAME might be preferable, if for example you've multiple services running from a single public IP, that you might want to split out in the future to run on separate IP's, at which point you can replace the CNAME records with A records.
Note, instead of an A record you can use a CNAME record if you prefer, though obviously the CNAME record will still need to point to a valid A record.  Using a CNAME might be preferable, if for example you've multiple services running from a single public IP, that you might want to split out in the future to run on separate IP's, at which point you can replace the CNAME records with A records.

Navigation menu