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 CE, external (when configured on the LDAP used by Carbonio CE, 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 CE. The supported methods are Carbonio, Carbonio CE’s local authentication backend, a Local LDAP, an External LDAP, or an External Active Directory server. You can refer to Section Authentication for more information about these backends.

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

Local LDAP#

The local LDAP authentication allows to define new users directly on Carbonio CE.

External LDAP#

A typical connection is shown in Fig. 9, the following scenario describes the parameters to be used.

Scenario

This scenario defines a few values that are used for the connection to an external LDAP server. Adapt them according to your needs!

  • Define on Carbonio CE the domain authentication.example.com

  • On an external LDAP server, located at 172.24.0.155, a domain called ldapexternal.local exists

    Note

    This external source can also be another Carbonio CE.

  • On the external LDAP server a dedicated admin user exists, that will be used for the LDAP connection (for example service.ldap@ldapexternal.local with password astrongpwd)

  • The LDAP class that stores the users and their password is called uid

Our goal is to have the authentication.example.com domain users authenticate with the passwords of the domain accounts ldapexternal.local defined on the external ldap server

URL

The hostname or IP address where the LDAP is located, which should include the port (default is 389). In our scenario it is 172.24.0.155:389.

Filter

Represents the attribute that identifies the user in the external LDAP (uid=%u).

Basic Search

The LDAP query that is used to filter the users. It contains the domain defined on the LDAP server (dc=ldapexternal,dc=local) and the organisation (or, in a broader sense, the LDAP class) to which the filter above belongs.

Search Bind user & Search Bind Password

The user password used to execute the query (user service.ldap@ldapexternal.local with password astrongpwd).

Verify Auth

This two fields allow to test whether an LDAP user, identified by username and password, can successfully authenticate.

../../_images/ap-ext-ldap.png

Fig. 9 An example connection to an external LDAP.#

See also

You can carry out the same procedure from the CLI, please refer to Section External LDAP.

External AD#

A typical connection is shown in Fig. 10, the following scenario describes the parameters to be used.

Scenario

This scenario defines a few values that are used for the connection to an external AD server. Adapt them according to your needs!

  • Define on Carbonio CE the domain ad-auth.example.com

  • On an external AD server, located at 172.24.0.100 a domain called external_ad.com exists

    Note

    This external source can also be another Carbonio CE.

  • On the external AD server a dedicated user exists, that will be used for the AD connection (for example service.ad@external_ad.com with password very_strong_pass!)

Our goal is to have the ad-auth.example.com domain users authenticate with the passwords of the domain accounts external_ad.com defined on the external ldap server

URL

The hostname or IP address where the AD is located, which should include the port (default is 3268). In our scenario it is 172.24.0.100:3268.

Filter

Represents the attribute that identifies the user in the external AD (|(userprincipalname=%u@external_ad.com)(samaccountname=%u)).

Basic Search

The query that is used to filter the users. It contains the domain defined on the AD server (dc=external_ad,dc=com).

Search Bind user & Search Bind Password

The user password used to execute the query (user service.ad@external_ad.com with password very_strong_pass!).

Verify Auth

These two fields allow to test whether an AD user, identified by username and password, can successfully authenticate.

../../_images/ap-ext-ad.png

Fig. 10 An example connection to an external AD.#

See also

You can carry out the same procedure from the CLI, please refer to Section External Active Directory.

Other options#

Once the selected authentication backend has been configured, a few additional options are available:

Enable Secure Connection

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

Virtual Hosts & Domain Certificates#

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 CE 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.

Infrastructure, wildcard, and domain certificates

During the Carbonio CE installation, a self-signed SSL certificate is created to allow basic access and configuration. However, before you put Carbonio CE in a production environment, you should install an infrastructure certificate.

The server-side generation of an infrastructure certificate or even a wildcard certificate is a task that can be carried out from the CLI only: check out section Deploy a Commercial SSL Certificate for directions.

If you do not plan to have additional domains configured on Carbonio CE, you’re all done: no additional certificate is needed.

If you need to configure multiple domains on the same Carbonio CE infrastructure, you can do it directly from the Carbonio Admin Panel, by generating a new certificate or uploading a commercial one that you have purchased. Let’s Encrypt certificates are also supported and can be generated from the Carbonio Admin Panel, see the procedure.

If you plan to allow IMAP or POP clients to connect to Carbonio CE, you need to always configure them using the FQDN of the Carbonio CE infrastructure, for example mail.example.com, independent of the number (and names) of the domains present on the Carbonio CE infrastructure.

Select the virtual host, then click 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). You can either click the paper clip icon to upload a certificate file or paste the content of the file in the corresponding textfields.

    Note

    If you paste the certificate, remember to add a carriage return (CR) at the end of the certificate (i.e., after the -----END CERTIFICATE----- line), like in the following screenshot.

    ../../_images/ap-cert.png

    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, 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 CE 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 gigabytes, 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 the quota, both total quota and percentage used. The list can be sorted by either quota.

Disclaimer#

Note

These settings are available only if the disclaimer is active in the global configuration (Domains ‣ Global ‣ Settings).

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 CE’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.