Web Files 
Account Data 

Many domain names can have DNS records pointing to your Server. But the Server automatically processes mail sent only to its Main Domain, or to one of its Secondary Domains.

To let the Server accept and locally process mail sent to any other domain, that domain should be mapped to any existing CommuniGate Pro domain. Otherwise, a message sent to an unlisted domain will be directed to the SMTP module for relaying, and that module, detecting that it has to send the message to itself, will reject the message reporting about a 'DNS loop'.

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.

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 and 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).

Direct Mapping (Domain Aliases)

Very often one real Domain should have several aliases (additional names). For example, if your CommuniGate Pro has the Domain, you may want the to process the and domain names as aliases for the Domain.

To create a Domain Alias, open the Domain Settings page and enter the name into the Aliases table. Click the Update button to see the alias name accepted, and enter the 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 name. As a result, messages sent to,, and to will all end up in the info Account in the CommuniGate Pro Domain.

The Router and Domain Aliases are also used for account access, so when a user tries to access the account, the info Account in the CommuniGate Pro Domain is opened.

You can use the Router domain records to achieve the same results: = =

You can also use the Router alias records:
<*>  = *
<*> = *

Modifying Mapping

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 CommuniGate Pro Domain wants to accept mail for the and addresses, but these accounts should not be the same as the info and order Accounts in the Domain.

Use the Router alias record to map the mail domain:
<*> = shop-*

This Router record will redirect mail sent to to Mail sent to will be redirected to, etc.

The Accounts shop-info and shop-order must exist in the Domain.

To access these accounts, the users should specify the 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 CommuniGate Pro domain:
<> =
<> =
<*> = *

Please note that the generic alias record must be specified after the first two records.

Unified Domain-Wide Accounts

You can tell the CommuniGate Pro Server to store all mail for a mail domain in one Account. This method is useful if:

To create a Unified Domain-Wide Account for the domain, use the following Router domain record: = client.local
or a Router alias record:
<*> = *@client.local

All messages to the 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 domain in one client account:
<*> = 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 address to be stored in the client-jim account in the Main CommuniGate Pro domain, while directing the rest of the mail to the Unified Domain-Wide Account client, use the following Router records:

<> = client-jim
<*> = *@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.

CommuniGate® Pro Guide. Copyright © 1998-2006, Stalker Software, Inc.