Access to CommuniGate Pro Accounts

Intro
Installation
SysAdmin
Objects
Transfer
Access
Sharing 
POP 
IMAP 
Web User 
LDAP 
ACAP 
PWD 
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo

The CommuniGate Pro server allows user to use various mailer applications to access their accounts and mailboxes.
  • The POP module is a POP3 server that allows users to retrieve mail from their INBOX mailboxes using the POP-based mailers.
  • The IMAP module is an IMAP4rev1 server that allows users to process mail messages in all account mailboxes using IMAP-based mailers.
  • The Web Email module is an HTTP (Web) server that allows users to process mail messages in all account mailboxes using any Web browser.
  • The LDAP module is an LDAP server that provides access to various directories and databases.
  • The ACAP module is an ACAP server that allows users to manage their accounts.
  • The PWD module is a poppwd server that allows users to change the account passwords using certain POP and IMAP mailers.

Access to Accounts

Every CommuniGate Pro account can be accessed via Access modules - POP, IMAP, Web Email, etc. Several client applications can use the same CommuniGate Pro account at the same, via the same, or different access modules.

Any mailbox in any CommuniGate Pro Account can be shared - in all senses.


Serving Multiple Domains

The main problem of serving multiple domains on one server is to provide access to accounts in several domains. In order to do this, the server should get the name of the domain name in which to look for the specified account. As for mail delivery, the server needs the "full account name" i.e. an address in the form accountname@domainname.

There are several methods to pass the domain name to the server:

All methods can be mixed in one server: a limited number of domains can be served using a dedicated additional IP addresses, while other domains are served using explicit domain name specifications.


Multihoming

Every access session begins with the authentication procedure: a mailer application passes a user (account) name and a password.

Since the server is designed to support multiple domains, it tries to detect which domain the account name belongs to.

Sample:
The server computer has 2 IP addresses: 192.0.0.1 and 192.0.0.2.
The server main domain is company.com, and the secondary domains are client1.com and client2.com.
The DNS A-records for company.com is pointing to the IP address 192.0.0.1,
the A-record for the client1.com points to a dedicated IP address 192.0.0.2, while the A-records for the client2.com domain point to the same "main" IP address 192.0.0.1.
Each domain has an account info.

Three users configure their POP and IMAP mailers to access an account info, but they specify different names in their "mail server" settings: the first user specifies company.com, the second - client1.com, and the third user specifies client2.com.

When the first user starts her mailer:

  • The mailer takes the specified "mail server" setting company.com, and it uses the Domain Name System A-records to resolve (convert) that name to the IP address 192.0.0.1.
  • The mailer establishes a connection with that address (which is one of 2 addresses of the server computer), and it passes the user name info.
  • The server detects a simple user name info and detects that this connection is established via the server address 192.0.0.1.
  • The server detects that the main domain name points to that IP address, so it adds the main domain name company.com to the specified simple name.
  • The server gets the correct full account name info@company.com.

When the second user starts checking mail:

  • The mailer takes the specified "mail server" setting client1.com, and it uses the Domain Name System A-records to resolve (convert) that name to the IP address 192.0.0.2.
  • The mailer establishes a connection with that address (which is one of 2 addresses of the server computer), and it passes the user name info.
  • The server detects a simple user name info and detects that this connection is established via the server address 192.0.0.2.
  • The server detects that the client2.com secondary domain name points to that IP address, so it adds the secondary domain name client1.com to the specified simple name.
  • The server gets the correct full account name info@client1.com.

When the second user starts checking mail:

  • The mailer takes the specified "mail server" setting client2.com, and it uses the Domain Name System A-records to resolve (convert) that name to the IP address 192.0.0.1.
  • The mailer establishes a connection with that address (which is one of 2 addresses of the server computer), and it passes the user name info.
  • The server detects a simple user name info and detects that this connection is established via the server address 192.0.0.1.
  • The server detects that the main domain name points to that IP address, so it adds the main domain name company.com to the specified simple name. The client2.com domain name also points to that IP address, but the server dedicates IP addresses to only one domain, and it always assigns it to the first domain it processes, the main domain company.com in our case.
  • The server gets the incorrect full account name info@company.com.
This happens because the mailer has not passed the information about the "mail server" name from its settings, and the only information the server has is the IP address. But since the IP address is the same for both main domain company.com and the secondary domain client2.com, the server is unable to detect which domain is needed and defaults to the main domain.

In order to solve this problem, the third user should specify the account name as info%client2.com, not just info. In this case, when this users starts the mailer:

  • The mailer takes the specified "mail server" setting client2.com, and it uses the Domain Name System A-records to resolve (convert) that name to the IP address 192.0.0.1.
  • The mailer establishes a connection with that address (which is one of 2 addresses of the server computer), and it passes the user name info%client2.com.
  • The server detects a full user name info%client2.com and it does not look at the IP addresses. It just converts the % symbol into the @ symbol.
  • The server gets the correct full account name info@company.com.
This problem does not appear if the third user uses the Web Interface: the server always gets the addressed domain name via the HTTP protocol, so it does not have to detect that name by looking at the IP addresses.
 

Routing

When the full account name is composed, this name (address) is passed to the Router.

This means that all routing applied to E-mail addresses is also applied to the account names specified with mailer applications.
Sample:
The account John has an alias John_Smith;
all E-mail messages addressed to John_Smith will be stored in the account John;
the user can specify either John or John_Smith as the "account name" setting in his mailer - in both cases the account John will be opened when his mailer starts a session.
 
Sample:
The account John has been moved from the main domain company.com to the domain client1.com, and it was renamed in j.smith. The administrator has created an alias record with the Router:
<John> = j.smith@client1.com;
all E-mail messages addressed to John@company.com will be stored in the account j.smith in the secondary domain client1.com;
the user can still specify just John as the "account name" setting, and the same company.com "mail server" setting in his mailer - but the server will open the account j.smith in the client1.com domain.
Note:
do not create an alias record that redirects the Postmaster account in the main domain. You will not be able to administer the server, if the postmaster account is redirected to an unexistant account or to an account that does not have the postmaster access rights.
If you want the postmaster mail to be directed to some other user, do not use the Router, but use the postmaster account Rules instead.

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