This chapter describes the components that are installed and reviews the configuration options that can be made when you install {product-name} ({product-abbrev}).
{product-name} can be easily scaled for any size of email environment, from very small businesses with fewer than 25 email accounts to large businesses with thousands of email accounts. Contact Zimbra Sales for more information about setting up your environment.
For the latest {product-name} software download, go to https://www.zimbra.com/downloads/. Save the {product-name} download file to the computer from which you will install the software.
When {product-name} is installed, the following Zimbra applications are saved to the Zimbra server.
You can access these download files from your Administration Console
Tools and Migration > Download page.
Instruction guides are available from the Help Center page or from https://www.zimbra.com/support/.
installconfig.adoc scanningattachments.adoc :leveloffset: -1
{product-short} Proxy (Nginx-Zimbra) is a high-performance reverse proxy server that passes IMAP[S]/POP[S]/HTTP[S] client requests to other internal {product-name} services. A reverse proxy server is an Internet-facing server that protects and manages client connections to your internal services. It can also provide functions like: GSSAPI authentication, throttle control, SSL connection with different certificates for different virtual host names, and other features.
In a typical use case, {product-short} Proxy extracts user login information (such as account id or user name) and then fetches the route to the upstream mail server or web server’s address from the Nginx Lookup Extension, and finally proxies the interactions between clients and upstream {product-name} servers. To accelerate the speed of route lookup, memcached is introduced, which caches the lookup result. The subsequent login with the same username is directly proxied without looking up in Nginx Lookup Extension.
You can install the {product-short} Proxy package on a mailbox server, MTA server, or on its own independent server. When the {product-short} Proxy package is installed, the proxy feature is enabled. In most cases, no modification is necessary.
Benefits for using the {product-short} Proxy include:
-
Centralizes access to Mailbox servers
-
Load Balancing
-
Security
-
Authentication
-
SSL Termination
-
Caching
-
Centralized Logging and Auditing
-
URLRewriting
For more information, see the wiki page https://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide
{product-short} Proxy is designed to provide a HTTP[S]/POP[S]/IMAP[S] reverse proxy that is quick, reliable, and scalable. {product-short} Proxy includes the following:
-
Nginx. A high performance HTTP[S]/POP[S]/IMAP[S] proxy server which handles all incoming HTTP[S]/POP[S]/IMAP[S] requests.
-
{product-short} Proxy Route Lookup Handler. This is a servlet (also named as Nginx Lookup Extension or NLE) located on the {product-name} mailbox server. This servlet handles queries for the user account route information (the server and port number where the user account resides).
Memcached is a high performance, distributed memory object caching system. Route information is cached for further use to increase performance. zimbra-memcached is a separate package that is recommended to be installed along with zimbra-proxy.
The following sequence explains the architecture and the login flow when an end client connects to {product-short} Proxy.
-
End clients connect to {product-short} Proxy using HTTP[S]/POP[S]/IMAP[S] ports.
-
Proxy attempts to contact a memcached server (elected from the available memcached servers, using a round-robin algorithm) if available and with caching enabled to query the upstream route information for this particular client.
-
If the route information is present in memcached, then this will be a cache-hit case and the proxy connects to the corresponding Zimbra Mailbox server right away and initiates a web/mail proxy session for this client. The memcached component stores the route information for the configured period of time (configurable and one hour by default). {product-short} proxy uses this route information instead of querying the Zimbra Proxy Route Lookup Handler/NLE until the default period of time has expired.
-
If the route information is not present in memcached, then this will be a cache-miss case, so {product-short} Proxy will proceed sending an HTTP request to an available {product-short} Proxy Route Lookup Handler/NLE (elected by round-robin), to look up the upstream mailbox server where this user account resides.
-
{product-short} Proxy Route Lookup Handler/NLE locates the route information from LDAP for the account being accessed and returns this back to {product-short} Proxy.
-
{product-short} Proxy uses this route information to connect to the corresponding {product-short} Mailbox server and initiates a web/mail proxy session. It also caches this route information into a memcached server so that the next time this user logs in, the memcached server has the upstream information available in its cache, and {product-short} Proxy will not need to contact NLE.The end client is transparent to this and behaves as if it is connecting directly to the {product-short} Mailbox server.
The following figure displays the positions of {product-short} Proxy and its relationships to other components of {product-name}.
The deployment strategy and position with respect to non-proxy hosts, {product-short} actively suggests using the Proxy server on the edge (either on an independent server or on the same server running LDAP/MTA) with mailbox servers behind it. In the case of multiple proxies, an external load balancer can be placed in front to distribute the load evenly among the proxy servers.
Note
|
The {product-short} Proxy package does not act as a firewall and needs to be behind the firewall in customer deployments. |
zimbra-proxy package needs to be selected during the installation process (it is installed by default). It is highly recommended to install memcached as well along with proxy for better performance.
Install zimbra-proxy [Y] Install zimbra-memcached [Y]
This would install and enable all IMAP[S]/POP[S]/HTTP[S] proxy components with the following default configuration.
Proxy configuration 1) Status: Enabled 2) Enable POP/IMAP Proxy: TRUE 3) IMAP proxy port: 143 4) IMAP SSL proxy port: 993 5) POP proxy port: 110 6) POP SSL proxy port: 995 7) Bind password for nginx ldap user: set 8) Enable HTTP[S] Proxy: TRUE 9) HTTP proxy port: 80 10) HTTPS proxy port: 443 11) Proxy server mode: https
Note
|
The following ports are used either by {product-short} Proxy or by {product-short} Mailbox
(if Proxy is not configured). If you have any other services running on these ports, turn them off. |
End clients connect directly to {product-short} Proxy, using the {product-short} Proxy Ports. {product-short} Proxy connects to the Route Lookup Handler/NLE (which resides on {product-short} Mailbox server) using the {product-short} Mailbox Ports.
{product-short} Proxy Port Mapping
{product-short} Proxy Ports (External to {product-name}) | |
---|---|
HTTP |
80 |
HTTPS |
443 |
POP3 |
110 |
POP3S (Secure POP3) |
995 |
IMAP |
143 |
IMAPS (Secure IMAP) |
993 |
{product-short} Mailbox Ports (Internal to {product-name}) | |
---|---|
Route Lookup Handler |
7072 |
HTTP Backend (if Proxy configured) |
8080 |
HTTPS Backend (if Proxy configured) |
8443 |
POP3 Backend (if Proxy configured) |
7110 |
POP3S Backend (if Proxy configured) |
7995 |
IMAP Backend (if Proxy configured) |
7143 |
IMAPS Backend (if Proxy configured) |
7993 |
You can configure multiple virtual hostnames to host more than one domain name on a server. When you create a virtual host, users can log in without having to specify the domain name as part of their user name.
Virtual hosts are configured from the administration console
Configure>Domains>Virtual Hosts
page. The virtual host requires a valid DNS configuration with an A record.
When users log in, they enter the virtual host name in the browser. For example, https://mail.example.com. When the {product-short} logon screen displays, users enter only their user name and password. The authentication request searches for a domain with that virtual host name. When the virtual host is found, the authentication is completed against that domain.