zarafa-gateway.cfg (5) - Linux Man Pages
zarafa-gateway.cfg: The Zarafa gateway configuration file
zarafa-gateway.cfg - The Zarafa gateway configuration file
The gateway.cfg is a configuration file for the Zarafa Gateway. gateway.cfg contains instructions for the software to set up the logging system and to enable or disable the POP3, POP3S, IMAP or IMAPS part of the service.
The file consists of one big section, but parameters can be grouped by functionality.
The parameters are written in the form:
name = value
The file is line-based. Each newline-terminated line represents either a comment, nothing, a parameter or a directive. A line beginning with `#' is considered a comment, and will be ignored by Zarafa. Parameter names are case sensitive. Lines beginning with `!' are directives.
Directives are written in the form:
The following directives exist:
Include and process
Example: !include common.cfg
EXPLANATION OF EACH PARAMETER
IP address to bind to. 0.0.0.0 for any address.
Hostname of the server to print to a client in the logon greeting. Leave empty to use DNS to find the hostname.
Whether to show the hostname in the logon greeting to clients. This config option is reloadable using the HUP signal.
Enable POP3 service with value yes. All other values disable the service.
The POP3 service will listen on this port for incoming connections.
Enable POP3S service with value yes. All other values disable the service.
The POP3S service will listen on this port for incoming connections.
Enable IMAP service with value yes. All other values disable the service.
The IMAP service will listen on this port for incoming connections.
Enable IMAPS service with value yes. All other values disable the service.
The IMAPS service will listen on this port for incoming connections.
The http address of the Zarafa server.
It is not advised to specify the UNIX socket here, but the http address instead. In default configuration the gateway will then be trusted by the Zarafa server (as set in its local_admin_users configuration setting). Unless is run as an untrusted user, by specifying the run_as_user, the gateway always authenticates users even if they provide no or wrong credentials!
After correctly starting, the gateway process will become this user, dropping root privileges. Note that the log file needs to be writeable by this user, and the directory too to create new logfiles after logrotation. This can also be achieved by setting the correct group and permissions.
Default value is empty, not changing the user after starting.
After correctly starting, the gateway process will become this group, dropping root privileges.
Default value is empty, not changing the group after starting.
Write the process ID number to this file. This is used by the init.d script to correctly stop/restart the service.
Change directory to this path when running in daemonize mode. When using the -F switch to run in the foreground the directory will not be changed.
You can change the process model between
thread. The forked model uses somewhat more resources, but if a crash is triggered, this will only affect one user. In the threaded model, a crash means all users are affected, and will not be able to use the service.
Enable the IMAP and IMAPS service to only show the mailfolders. This is the default behaviour. When this option is set to 'no', you will also be able to select you calendar and contacts and such. These views will not contain all information, since these items cannot be converted to a rfc-822 mail item.
Enable the IMAP and IMAPS service to also show the public store with subfolders. This is the default behaviour. When this option is set to 'no', IMAP clients will only see the users' folder.
Allow IMAP clients to issue the IDLE command. When an IMAP client is idle, it may receive notifications from the server about changes of the selected folder. This may increase load on the server when many users are using the IMAP service.
Normally e-mails specify the correct charset for their contents. This may be altered to make it always UTF-8. This will only happen on e-mails that do not have the extra imap data properties, which is true for users without the 'imap' feature enabled.
Limit the maximum message size (in bytes) which can be created by an IMAP client. The maximum of this value is 4GB although this is not recommended. If the value is too high it will cause a segmentation fault. This value may contain a k, m or g multiplier.
Normally when you delete an e-mail in an IMAP client, it will only be marked as deleted, and not removed from the folder. The client should send the EXPUNGE command to actually remove the item from the folder (where Zarafa will place it in the soft-delete system). When this option is set to
yes, the zarafa-gateway will issue the expunge command itself directly after a 'mark as delete' command was received.
Store the rfc822 data with the message in MAPI. The Zarafa Gateway stores the original rfc822 data of an APPENDed message in the database for later retrieval. This makes sure that the exact message that was delivered into the Zarafa gateway is available for retrieval later, which is the behaviour when set to
yes. If set to no, the zarafa-gateway will not store the original rfc822 text. This means that the rfc822 data must be re-created when retrieved. This may cause changes in encoding or charset and some loss of fidelity. This will also invalidate any signatures in the stored messages.
Maximum of failed commands before forcibly closing connection of client. This makes sure that a client which does repeatedly fails on a specific connection (like opening folders over and over again which do not exist) does not affect the overall performance of the gateway process. With the default value set to
10, normal operation will work for most productionenvironments. With IMAP migrations, this value should be set higher as many traditional IMAP migration tools try to fetch folders which do not necessarily exist before, so in a migration scenario this value should be set higher, at minimum to the number of folders to be migrated from the largest mailbox.
Disable all plaintext POP3 and IMAP authentications unless SSL/TLS is used (except for connections originating from
to allow saslauthd with rimap). Obviously enabling this configuration option requires at least
to take effect.
The gateway will use this file as private key for SSL TLS. This file can be created with:
openssl genrsa -out /etc/zarafa/gateway/privkey.pem 2048.
The gateway will use this file as certificate for SSL TLS. A self-signed certificate can be created with:
openssl req -new -x509 -key /etc/zarafa/gateway/privkey.pem -out /etc/zarafa/gateway/cert.pem -days 1095.
Enable client certificate verification with value yes. All other values disable the verification.
The file to verify the clients certificates with.
Default: value not set.
The path with the files to verify the clients certificates with.
Default: value not set.
Disabled or enabled protocol names. Supported protocol names are
TLSv1. If Zarafa was linked against OpenSSL 1.0.1 or later there is additional support for the new protocols
TLSv1.2. To exclude both, SSLv2 and SSLv3 set
!SSLv2 !SSLv3. SSLv2 is considered unsafe and these connections should not be accepted.
SSL ciphers to use, set to
for backward compatibility.
Prefer the server's order of SSL ciphers over client's.
The method which should be used for logging. Valid values are:
- Use the Linux system log. All messages will be written to the mail facility. See also syslog.conf(5).
- Log to a file. The filename will be specified in log_file.
When logging to a file, specify the filename in this parameter. Use
(minus sign) for stderr output.
The level of output for logging in the range from 0 to 5. 0=no logging, 5=full logging.
Specify whether to prefix each log line with a timestamp in 'file' logging mode.
The following options are reloadable by sending the zarafa-gateway process a HUP signal:
- The Zarafa gateway configuration file.