Mapping

Intro
Installation
SysAdmin
Objects 
Domains 
Mapping
Accounts 
Groups 
Forwarders 
Mailboxes 
Account Data 
Transfer
Access
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo

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

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

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 on one of the existing 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 client1.com and client2.com are CommuniGate Pro domains, both domains can have the account info, and these accounts are different accounts - each 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 company.com secondary domain, and you want the mail.company.com and relay.company.com to be processed as that domain aliases.

To create a domain alias, open the company.com Domain Settings page and enter the mail.domain.com and relay.company.com names into the Aliases table.

Created aliases will tell the Router that all references to these two domain names should be substituted with the domain.com name. As a result, messages sent to info@domain.com, info@mail.domain.com, and to info@relay.domain.com will all end up in the info account in the domain.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.domain.com account, the info account in the domain.com CommuniGate Pro domain is opened.

You can use the Router alias records to achieve the same results:
<*@mail.domain.com>  = *@domain.com
<*@relay.domain.com> = *@domain.com


Modifying Mapping

Sometimes you do not want to create a separate CommuniGate Pro domain for a mail domain (for example, if the 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 accounts, but these accounts should be different from the info and order accounts in the client.com domain.

Use the Router account records to map the shop.client.com 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.


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 client.com domain, use the following Router record:

client.com = client.local

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.

You can also use a Router alias record:

<*@client.com> = *@client.local

The Local Delivery Module will use 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 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.


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