| Version 5.4
Introduction
Installation
SysAdmin
Network
Objects
Storage
E-mail
Real-Time
Access
Services
Directory
Clusters
Applications
Miscellaneous
Licensing
WebMail
Pronto!
PBX
Overview | POP | IMAP | WebUser | XIMSS | MAPI | AirSync | WebDAV | FTP | TFTP | ACAP
# Account Access Access to Accounts Serving Multiple Domains Multihoming Routing The CommuniGate Pro Server allows users to use various client applications to access data in their Accounts: Mailboxes, Calendars, Contacts, Files, etc. The POP module is a POP3 server; it allows users to retrieve E-mail messages from their INBOX Mailboxes (and, optionally, other mailboxes) using POP3-based mailers. The IMAP module is an IMAP4rev1 server; it allows users to process E-mail messages in all Account Mailboxes using IMAP-based mailers. The WebMail module is an HTTP (Web) application server; it that allows users to process E-mail messages in all Account Mailboxes and employ other CommuniGate Pro Server features using any Web browser. The XIMSS module is an XML Messaging, Scheduling, and Signaling server; it allows users to make and control calls, to process E-mail messages and groupware items in all Account Mailboxes and employ other CommuniGate Pro Server features using "rich" Web-based clients (such as Flash®-based clients). The MAPI module is an extension of the IMAP module; it allows users to access their Accounts and Mailboxes via the Microsoft® Windows MAPI (Mail API) and to use the Microsoft Outlook client in its full-featured "groupware" mode. The AirSync module is an extension of the HTTP module; it allows users to access their Accounts and Mailboxes via the Microsoft® ActiveSync/AirSync protocol and to use the Windows Mobile clients to receive and send E-mail messages, and to synchronize Contacts, Calendar, and Tasks information with the Server Account data. The CalDAV module is an extension of the HTTP module; it allows users to access their Calendar-type and Task-type Mailboxes via the CalDAV protocol. The CardDAV module is an extension of the HTTP module; it allows users to access their Contact-type Mailboxes via the CardDAV protocol. The HTTP module is an HTTP server; it serves as a transport layer for other modules (such as the AirSync, and WebDAV modules, the XIMSS module in the HTTP Binding mode, etc.), and it provides access to Account File Storage, Mailboxes, and the Account Groupware information. The FTP module is an FTP server; it provides access to Account File Storage. The TFTP module is a TFTP server; it provides access to Account File Storage. The ACAP module is an ACAP server; it allows users to manage their custom application settings stored in their Account datasets.

## Access to Accounts

Every CommuniGate Pro Account can be accessed via the Access modules - POP, IMAP, XIMSS, WebUser Interface, FTP, XMPP, etc. Several client applications can use the same CommuniGate Pro Account at the same time, via the same, or different access modules.

Any Mailbox in any CommuniGate Pro Account can be shared: it can be accessed not only by the Account owner, but also by other users - if the Account owner or an Administrator grants those users access rights for that Mailbox.

## Serving Multiple Domains

The main problem of serving multiple domains on one server is to provide access to accounts in different domains. To look for the specified Account, the server should get the name of the Domain to look in.
Access to Accounts is similar to E-mail delivery and Signal processing: the server needs to know the "full Account name" - an address in the accountName@domainName form.

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

- A client application explicitly specifies the domain name.
  - If a user accesses the Server via the HTTP (Web interface), this happens automatically: the user first specifies the server URL (`http://domainname:port`), and then enters the Account name in the Login form.
    Since all modern browsers pass the original URL to the server, the domain name becomes known, and the HTTP module immediately appends that domain name to a simple user name specified in the Login form.
  - If a user accesses the Server using an XMPP, this happens automatically: the user first specifies the server name in the client application settings, and the client application sends that data as the 'to' attribute in the XML streams.
  - If users access the Server with POP or IMAP mailers, they can specify the full account name in the mailer "account name" settings.
    Since many mailers do not accept the `@` symbol in account names, the `%` symbol can be used instead.
    The user `john` with an Account in the secondary Domain client1.com should specify the Account name as `john%client1.com`, not just as `john`.
  - If users access the Server with XIMSS client applications, these applications always specify the full Account name for the authentication operations.

- The domain name can be detected using multihoming. If it is impossible to force users to access the server via the Web interface or to make them enter full account names in their POP/IMAP mailers, multihoming can be used.
  A server is using multihoming if the server computer has more than one Internet (IP) address. Using the Domain Name System (DNS) the secondary domains can be assigned different IP addresses.
  If a secondary Domain has an IP address assigned to it, and a user connects to that IP address, all simple account names specified with the user mailer are processed as names in that Domain.
  It may be difficult to assign an IP address to each Domain, so this method should be used only if it is impossible to make users specify domain names explicitly.

These methods can be used together: a limited number of Domains can be served using dedicated additional IP addresses, while other Domains are served using explicit domain name specifications.

## Multihoming

Every access session begins with the authentication procedure: a client application sends a user (Account) name and a password to the Server.

The CommuniGate Pro Server tries to detect which Domain it should use to look for the specified Account name.

- If the specified name contains the `@` symbol or the `%` symbol, the Server assumes that the user has specified a "full account name", i.e. an Account (or other Object) name with its Domain name: `username@domainname` or `username%domainname` (see above).
- If the specified name does not contain the `@` symbol or the `%` symbol, the Server looks at the IP address on which it has received this connection.
  Systems with multihoming (i.e. systems that have several local IP addresses) may have certain IP addresses assigned to some Domains. If a connection IP address is assigned to a some Domain, that domain name is appended to the account name to get the full account name. If the address is dedicated to the Main Domain, the specified name is processed as the Main Domain name.
  By default, all Server IP Addresses are assigned to the Main Domain.

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 clients to access an account `info`, but they specify different names in their "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 client application takes the specified "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 client 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 this IP address is assigned to the Main Domain, 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 her client application:
  - The client takes the specified "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 client 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 this IP Address is assigned to the client1.com secondary Domain, so it adds that Domain name to the specified simple name.
  - The Server gets the correct full account name `info@client1.com`.

  When the third user starts her client application:
  - The client takes the specified "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 client 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 this IP address is assigned to the Main Domain, so it adds the Main Domain name company.com to the specified simple name.
  - The server gets the incorrect full account name `info@company.com`.

  This happens because the client application (usually - an old POP or IMAP mailer, and FTP client, etc.) has not passed the information about the "server" name from its settings, and the only information the Server had was the IP address.

  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 user starts the client application:
  - The client takes the specified "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 client 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@client2.com`.

  Note: most FTP clients work in the same way as the POP/IMAP mailers do, so FTP users are required to supply qualified Account names unless they connect to an IP Address assigned to their Domain.

  Note:the MAPI Connector always sends a qualified Account Name: if users specify names without the `@` or `%` symbols, the Connector adds the '@' symbol and `Server Name` setting value to the specified account name.

  Note:the XMPP clients send the 'target domain' name along with the login name. If the specified login name does not contain the `@` or `%` symbols, the Server adds the '@' symbol and "target domain" name to the login name.

## Routing

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

- If the Router reports an error, the client is not authenticated and an error message is returned to the client application. An error is usually the `Unknown user` error, but it can be any error that Router or modules can generate when routing an address.
- If the Router has successfully routed the address, but the address is not routed to the Local Delivery module, the client is not authenticated and an error message is returned to the client application. This happens if a user has specified a mailing list name, not an account name, or if the specified name is rerouted to some other host (via SMTP, for example).
- If the Router routed the address to some Account in some local Domain, that Account is opened, and the Account passwords are checked.

This means that all routing applied to E-mail and Signal addresses is also applied to the account names specified with mailer applications.

Sample:
  The Account `john` has a `john_smith` alias;
  all E-mail messages and Signals addressed to john_smith will be delivered to the Account john;
  the user can specify either john or john_smith as the "account name" setting in his client applications - in both cases the Account `john` will be opened when those applications connect to the Server.
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 a Router record:
  `<John> = j.smith@client1.com`;
  all E-mails and Signals addressed to john@company.com will be sent to the Account j.smith in the client1.com Domain;
  the user can still specify just `john` as the "account name" setting, and the same company.com "server" setting in his client application - but the Server will open the Account j.smith in the client1.com Domain.

Note:
  do not create any Router record that redirects the Postmaster Account in the Main Domain. You will not be able to administer the Server, unless the postmaster account is redirected to an Account that has the Master access rights.
  If you want the Postmaster E-mails and Signals to be directed to some other user, do not use the Router, but use the postmaster Account Rules instead.

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