CommuniGate Pro provides a variety of methods to serve multiple domains. The Server Administrator should decide how to serve each domain and either create a new full-scale Secondary Domain or just map a mail domain name onto one of the existing CommuniGate Pro Domains.
Each CommuniGate Pro domain has its own set of accounts, own settings, own WebUser Interface, etc. If client1.com and client2.com are CommuniGate Pro domains, both domains can have the account info, and these Accounts are different - each one with its own settings, mailboxes, passwords, etc.
Each CommuniGate Pro Domain can have its own Domain Administrator(s).
To create a Domain Alias, open the company.com Domain Settings page and enter the mail.domain.com name into the Aliases table. Click the Update button to see the alias name accepted, and enter the relay.company.com name into the new empty field. Click the Update button again.
Created aliases will tell the Router that all references to these two domain names should be substituted with the company.com name. As a result, messages sent to firstname.lastname@example.org, email@example.com, and to firstname.lastname@example.org will all end up in the info Account in the company.com CommuniGate Pro Domain.
The Router and Domain Aliases are also used for account access, so when a user tries to access the email@example.com account, the info Account in the company.com CommuniGate Pro Domain is opened.
You can use the Router domain records to achieve the same results:
mail.company.com = company.com
relay.company.com = company.com
You can also use the Router alias records:
<*@mail.company.com> = *@company.com
<*@relay.company.com> = *@company.com
For example, your client with client.com CommuniGate Pro Domain wants to accept mail for the firstname.lastname@example.org and email@example.com addresses, but these accounts should not be the same as the info and order Accounts in the client.com Domain.
Use the Router alias record to map the shop.client.com mail domain:
<*@shop.client.com> = firstname.lastname@example.org
This Router record will redirect mail sent to email@example.com to firstname.lastname@example.org. Mail sent to email@example.com will be redirected to firstname.lastname@example.org, etc.
The Accounts shop-info and shop-order must exist in the client.com Domain.
To access these accounts, the users should specify the client.com name as the name of their mail server, and shop-info, shop-order, etc. as their account names.
You can use this method to modify just some of the additional domain account names, while
mapping other names directly to the names in the client.com CommuniGate Pro domain:
<email@example.com> = firstname.lastname@example.org
<email@example.com> = firstname.lastname@example.org
<*@shop.client.com> = *@client.com
Please note that the generic alias record must be specified after the first two records.
To create a Unified Domain-Wide Account for the client.com domain, use the following Router domain record:
All messages to the client.com mail domain will be stored in the client Account in the CommuniGate Pro Main Domain. The .local suffix explicitly tells the Local Delivery Module to accept this address and direct it to the client account.
The Local Delivery Module uses the local part of the address to form the X-Real-To: header fields in the stored messages. These fields will allow the client software to retrieve messages from the CommuniGate Pro Unified Domain-Wide Account and distribute them locally to the proper users of that mail domain. See the Local Delivery Module section for more details.
If users of such mail domain do not have their own mail server that retrieves mail from the Unified Domain-Wide Account, but connect to your CommuniGate Pro Server directly, the POP module will show each user only the messages directed to that user, rather than all messages stored in the Unified Domain-Wide Account. See the POP Module section for more details.
Please note that while the following Router record will also store all mail sent to the
client.com domain in one client account:
<*@client.com> = client
But this Router record discards the information about the original user name (the part before the @ sign). As a result, no X-Real-To: header fields will be added to the messages stored in the client account.
You can mix the mapping methods with the Unified Domain-Wide Account method. For example, if you want messages sent to the email@example.com address to be stored in the client-jim account in the Main CommuniGate Pro domain, while directing the rest of the client.com mail to the Unified Domain-Wide Account client, use the following Router records:
<firstname.lastname@example.org> = client-jim
<*@client.com> = *@client.local
If you are serving many small mail domains, providing Unified Domain-Wide Accounts can be a very effective alternative to real CommuniGate Pro domains.