Version 5.1
Objects |
|---|
| |||||||||
|
|
Version 5.1 |
|||||||||||||||||||||||||||||||
|
|
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.
The CommuniGate Pro Server allows you to create Secondary Domains in addition to the Main Server Domain. In this section the Main and Secondary domains are referenced as real or 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).
Very often one real Domain should have several aliases (additional names). For example, if your CommuniGate Pro has the company.com Domain, you may want the to process the mail.company.com and relay.company.com domain names as aliases for the company.com Domain.
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 info@company.com, info@mail.company.com, and to info@relay.company.com 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 info@mail.company.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
Sometimes you do not want to create a separate CommuniGate Pro Domain for a mail domain (for example, if that mail domain will have only few accounts), but you do not want the account names in that mail domain to interfere with the account names in the CommuniGate Pro Domain you map it on.
For example, your client with client.com CommuniGate Pro Domain wants to accept mail for the info@shop.client.com and order@shop.client.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> = shop-*@client.com
This Router record will redirect mail sent to info@shop.client.com to shop-info@client.com. Mail sent to order@shop.client.com will be redirected to shop-order@client.com, 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:
<info@shop.client.com> = shop-info@client.com
<order@shop.client.com> = shop-order@client.com
<*@shop.client.com> = *@client.com
Please note that the generic alias record must be specified after the first two records.
You can tell the CommuniGate Pro Server to store all mail for a mail domain in one Account.
This method is useful if: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
@ symbol). 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 jim@client.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:
<jim@client.com> = 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.