Ctrl+K
What do you think about our new Documentation Layout? Take the survey
Back to Documentation Hub

Details

Details#

In the various subsection present in Details, it is possible to refine the configuration of the domain. Values for most of the options (for example the Time Zone), if not specified for a given domain, are inherited from the main domain defined.

General Settings#

General setting influence the basic domain configuration; most of them appear during the creation of the domain. Additional options allow to define the time zone, the use of HTTP or HTTPS protocol (we suggest using always the latter), and a mail server used for spam-relay purposes.

Moreover, a default COS and its status can be attached to the domain.

COS statuses

A COS can be defined for a whole domain or an account and determines its status, that is, its ability to log in to the domain and access the e-mail. If the domain COS and a user’s COS differ, the resulting status of the account is shown. Each COS can be defined with one of the following five values.

  1. Active. The COS is enabled, therefore the domain and its accounts can be used for everyday operations.

  2. Closed. The domain is shut down, no access is granted, and all incoming e-mails are rejected.

    Hint

    This status overrides the individual accounts COS status.

  3. Locked. In this state, user access is not possible, unless individual accounts are marked as Active. Incoming e-mails are regularly delivered to the accounts.

  4. Maintenance. Users can not log in, their incoming e-mails are not delivered but are kept in a queue by the MTA. If the account’s status is closed, it overrides the domain status setting, that is, the user’s incoming e-mails are rejected.

  5. Suspended. A status similar to maintenance, with the difference that no accounts or distribution lists can be changed. If the account’s status is closed, it overrides the domain status setting, that is, the user’s incoming e-mails are rejected.

We build on the domain created in previous section and attach some property.

Public Service Protocol

Force clients to connect only using https.

Time Zone

The timezone is set to Hawaii’s time.

Default Class of Service

The COS used by the domain, which is left to the default one.

Public Service Host Name

It is the FQDN (mail.acme.example) used by clients to connect to the domain and must correspond to the DNS A record to be reachable publicly. If the A record is set to a private IP address, to reach the WebGUI you need some mechanism, like e.g., a VPN tunnel.

../../_images/domain-details.png

At the bottom of the page, button DELETE DOMAIN allows to delete the domain. When clicked, a dialog will open, listing all items defined on the domain (Accounts, Distribution Lists, Resources, and so on) and that will be deleted together with the domain. Two choices are available: to Close the domain, keeping all items but preventing access, or Remove the domain and all its items.

Warning

The removal of the domain is an operation that can not be undone: all the items are gone forever.

Global Address List#

A GAL is a special account (“GALSync Account”) that contains all e-mail accounts configured on the server and provides the ability to quickly search e-mail addresses, for example when composing an email or adding participants to an event in the Calendar. A GAL can be internal when configured on Carbonio, external (when configured on the LDAP used by Carbonio, or both. In this page you see the email-address of the GALSync account, you can change it from external to internal, or vice versa, or both. you can also remove it, create it if missing, and change some of its options.

The GALSync account is updated regularly, according to the interval specified in the Settings section of the page. Administrators can force a resynchronisation of all GALs defined on a domain by clicking the RE-SYNC button.

Authentication#

Options in this page control how a user can log in to Carbonio. The supported methods are Default, Carbonio’s local authentication backend, a Local LDAP, an External LDAP, or an External Active Directory server.

If the method is different from Default, you need to provide the various parameters and check it the connection is successful.

Below the methods, a few additional options are available:

Show “Forget password” link in the login page

With this option enabled, a user can proceed to recover a lost password, by sending an email address to the configured recovery address (see tab Security in Carbonio Admin Panel’s Accounts Section).

Try local password management in case of failure with other methods

This option enables user to login with the Default auth method in case other backends are not available.

Enable Secure Connection

By disabling this option, users can login using an unencrypted HTTP connection.

Virtual Hosts & Certificate#

A Virtual Host is an alternative name given to a domain that can be used to access the same domain. To be able to use the virtual host, the name must be registered on the domain’s DNS with an A or CNAME record.

To each virtual host you can associate an SSL certificate. Carbonio supports the upload of multiple SSL domain certificates from the Carbonio Admin Panel and associate them to different domains, a procedure that requires only a few steps.

Note

The generation of server-side certificates directly on Carbonio and the management of wildcard certificate are tasks that can be carried out from the CLI only: check out section Deploy an SSL Certificate if you need to use either of them.

Select the virtual host, then click UPLOAD AND VERIFY CERTIFICATE. In the dialog, you can choose to use:

  • A Let’s Encrypt longChain Certificate, i.e., including an intermediate certificate. Make sure to satisfy the requirements before clicking the GENERATE CERTIFICATE button. Complete the procedure according to the directions below.

  • A Let’s Encrypt shortChain Certificate, without intermediate certificate: like the previous case, make sure to satisfy the requirements before clicking the GENERATE CERTIFICATE button. Complete the procedure according to the directions below.

    Let’s Encrypt’s Short and Long Chain certificates.

    Without going into much details, the difference between the two types of certificates issued by Let’s Encrypt (“ISRG Root X1”) is the compatibility with older Android clients and SSL libraries.

    More technically, the difference is that the Short Chain contains two certificates: Let’s Encrypt’s Root certificate and the one issued to your website, signed by the former; while the Long Chain three: the same of the Short Chain and an intermediate certificate. The ISRG Root X1 indeed, was issued quite recently and may not be known to some browsers, devices, or clients, therefore it was decided to add as intermediate certificate another root certificate that is well known to clients, to expand compatibility.

    See also

    More details and technicalities about the Short vs. Long Chain certificates can be found in article Long (default) and Short (alternate) Certificate Chains Explained.

  • A custom certificate. In this case, you need to provide by yourself the three files of the authorisation chain (i.e., the Domain Certificate, the Certificate CA Chain, and the Private Key) in the first or copy the content of the individual files in the appropriate fields. Click VERIFY to verify the certificates: if everything is correct, notification The certificate is valid will appear. To use the certificate, click the I WANT TO USE THIS CERTIFICATE button to upload and use the certificate. Again, a notification will be shown (The certificates have been saved). To complete the procedure: if you are on a Single-Node, restart it otherwise you need to restart the node on which the Proxy is installed.

You can REMOVE or DOWNLOAD the certificates by clicking the appropriate button above the certificates themselves.

Install a Let’s Encrypt certificate#

Let’s Encrypt Requirements

Before attempting to ask for a Let’s Encrypt certificate, make sure that:

  1. Public Service Protocol and Public Service Host Name are correctly set in the Carbonio Admin Panel’s Domain ‣ General Settings

  2. There is a Virtual Host correctly configured for the domain you want the certificate

  3. A, AAAA, and CNAME records are configured in the domain’s DNS configuration

  4. The domain has a valid FQDN that can be resolved from anywhere (i.e., the domain must be publicly accessible)

  5. The Proxy Nodes are reachable from the Internet on port 80 (http). In case the proxy can not be directly reached, you must add some forwarding rules.

  6. You run all command in this section as the zextras user

  7. The zimbraReverseProxyMailMode attribute has been set to redirect at global level. You can verify if this is the case with command

    zextras$ carbonio prov gacf zimbraReverseProxyMailMode

    If the output is not redirect, you can set it with

    zextras$ carbonio prov mcf zimbraReverseProxyMailMode redirect

  8. you have unset the same attribute on the Proxy Nodes

    zextras$ carbonio prov ms $(zmhostname) zimbraReverseProxyMailMode ""

  9. (Optional) To receive e-mail responses from Let’s Encrypt, Carbonio attributes carbonioNotificationRecipients and carbonioNotificationFrom are defined at global level.

Hint

If you have more than one Proxy Node, execute the commands on each Proxy Node.

Once done, execute the following commands to pick up the changes on the Proxy Node

zextras$ /opt/zextras/libexec/zmproxyconfgen
zextras$ zmproxyctl restart

To correctly issue a Let’s Encrypt certificate for your Carbonio installation, you should carry out the following steps.

The starting point is to generate the certificate using the Carbonio Admin Panel button, as shown in the previous section. besides the message on the bottom right corner, you will receive in a few minutes an e-mail, provided you set Carbonio attributes, see list above, stating the success or failure of the certificate’s generation.

Hint

You can follow the process by checking the log file /var/log/carbonio/letsencrypt/letsencrypt.log on the Proxy Node, using the tail -f command from the CLI.

In case of failure, the e-mail will report the errors encountered that you need to fix before attempting again. Take into account that if you continuously ask for a certificate without success, you can be temporarily be prevented to ask again.

The message Successfully received certificate appears in the e-mail when the issue is successful, together with other information, including the expiry date, followed by a second confirmatory e-mail.

At this point you can deploy the certificate on your infrastructure. Log in to the CLI and issue, as the zextras user, the commands

zextras$ /opt/zextras/libexec/zmproxyconfgen
zextras$ /opt/zextras/bin/zmproxyctl reload

The certificate expires after 90 days, and, according to Let’s Encrypt recommendations should to be renewed 30 days before expiration. you can check the certificate status and renew it from CLI, either manually or automatic, please refer to section Renew a Let’s Encrypt Certificate for directions.

Once done, run again the two deployment commands

zextras$ /opt/zextras/libexec/zmproxyconfgen
zextras$ /opt/zextras/bin/zmproxyctl reload

Mailbox Quota#

These settings allow to define a maximum limit (in bytes, with 0 meaning no limit) for the space used by each account and by the entire domain. It is also possible to set a value that, when reached, will send a warning by e-mail to a given address. The values configured here are inherited by all accounts that will be created, but can be overridden on a per-user basis.

To ease monitoring user’s quota, the bottom of the page contains a list of accounts and of their used quota.

Whitelabel Settings#

These setting are the same that appear in Global’s Whitelabel Settings section, but are domain-specific: if not defined at domain level, the global theme settings will be applied.

2-Factor-Autentication#

In this page it is possible to configure 2FA for the various services offered by Carbonio, only for the selected domain. To modify settings for all domains, refer to 2-Factor-Autentication.

Many services are available to configure individually. For each of them it is possible to Disable 2FA completely, allowing user access with username and password only; to Trust the IP, meaning that all client connections from a given IP address or IP range will be trusted even if they don’t use 2FA; and to Trust the device which allows an application (usually a browser) to be trusted when connecting from a given IP.

Hint

2FA applies only to those protocols or apps supporting it, for example HTTP and HTTPS but not to IMAP and SMTP.

SAML#

The management of SAML access to Carbonio is carried out from this page.

See also

The same SAML configuration tasks can be carried out from the CLI, please refer to Section Setting up SAML Configuration.

At the top of the page, two buttons allow to copy the ENTITY ID and SERVICE URL of the current Carbonio, which are required to carry out the configuration on the SAML IDP provider’s side: click each of them to paste the respective value and generate the configuration.

Once the configuration has been carried out, it is possible to copy its URL and paste it in the textfield. Click the Allow Unsecure if the configuration URL uses HTTP and not HTTPS. Click IMPORT to import the configuration.

The three button below allow to generate the SP certificate to configure the logout from the IDP and to export or delete the current configuration.

The procedure to follow for the complete logout from the IDP is described in detail in the CLI Section Configure SAML Logout. You can accomplish the same goal from the Carbonio Admin Panel by writing in the two bottom textfields the variables mentioned in that section and their corresponding value, then clicking the ADD button. Remember also to add the SP certificate to the IDP’s configuration.

Disclaimer#

To add a disclaimer to e-mails, use either textfield present in the page. The text written in the left-hand side will be appended to e-mails of users that have the mail editor set for plain-text, while the text written in the right-hand side is for user using the rich-text editor.

Please check the Carbonio’s global settings for further configuration.

The text can contain for example a legal, confidentiality, or copyright notice: an example in text:

This email and any files transmitted with it are confidential and
are for the sole use of the individual or entity to which they are
addressed. If you received this email in error, please notify your
system administrator.

One example in HTML:

<h2>Contacts</h2>
<p>Company Phone: +00 123 456 7890</p>
<p>Company e-mail: info@example.com</p>

Every time you enable or disable the disclaimer or change the text, you need to issue the command as the zextras user on every Node featuring the MTA role

zextras$ /opt/zextras/libexec/zmaltermimeconfig

See also

Domain disclaimer can be managed from the CLI as well, please refer to Section Configuring Domain Disclaimer.

Contents