How To

How can I gradually migrate accounts from my old server?

In many cases, especially when you migrate users from an old server, you may want CommuniGate Pro to deliver mail to all Accounts created in a certain Domain, while mail to all Accounts that do not [yet] exist in that CommuniGate Pro Domain should be relayed to some other [old] server, without any change in the headers and envelope addresses.

Open the Domain Settings for that Domain and set the Mail to Unknown option:

Here domain.dom is the name of this CommuniGate Pro Domain and otherserver.dom is the DNS name of the other [old] server. If the DNS name for the other server does not exist, you can use the IP address instead:

When the CommuniGate Pro server receives any message directed to aname@domain.dom, and the Domain does not have an Account/Group/Forwarder/Mailing List with that aname name, the message is Rerouted (the envelope address is changed) to aname%domain.dom@otherserver.dom._via. The ._via suffix tell the Router module to accept this address, and to cut off the domain name, using that part only as a name of the server to connect to (the Router module always cuts off the IP-address domain parts, too). The resulting envelope address (aname%domain.dom) is converted to the standard form (aname@domain.dom) before it is sent to that other server. As a result, the other server receives such a message with the unmodified envelope data and header fields.

As soon the aname Account is created in the CommuniGate Pro domain.dom Domain, mail starts to go to that Account automatically. You can copy all messages from the aname account on the old server to the aname Account on the new server and phase out the aname account on the old server.

How can I relay E-mail and Signals for certain domains?

To allow your Server to relay all E-Mail and Signals to the friend.com domain place the following record into the Router table:

Read the Protection section to learn the meaning of the Relay: prefix (you can omit it, or you may want to use the RelayAll: prefix instead).

If you want to relay E-mail and Signals for the friend.com domain, but they should go via some different firewall.friend.com server, use the following Router record:

If you want to bypass the MX or SRV records and relay all E-mail and Signals to a certain IP address (specified explicitly or using a DNS A-record), then see the Bypassing MX/SRV section.

If you want your Server to act as a backup E-mail relay for certain domains, you can enable the Relay to All Hosts We Backup option in the SMTP module settings.
This is not a perfect solution, since anybody who can modify DNS records for certain domains can use your server as a backup relay for those domains.

How can I send E-mail and Signals to a remote host bypassing its DNS MX/SRV records?

If your Server should send E-mail and Signals to the target.domain domain via the relay.domain relay server or proxy, you can specify the IP address of that relay with a Router record:

You may want to relay E-mail and Signals using DNS A-records instead of explicitly specified IP addresses:

The SMTP module does not look at the MX records if the port number of a remote host is explicitly specified. By specifying the standard (25) SMTP port number, you tell the SMTP module to look for the relay.domain DNS A-record, and ignore its MX records.

The SIP module does not look at the SRV records if the port number of a remote host is explicitly specified. By specifying the standard (5060) SIP port number, you tell the SIP module to look for the relay.domain DNS A-record, and ignore its SRV records.

Note: You may want to add a Relay:, NoRelay: or RelayAll: prefix to these Router records.

How can I forward mail to the other SMTP MTA on the same server?

You may want to have two different SMTP Servers (MTA) running on the same computer, but listening on either different port numbers or on different IP addresses.

To relay mail to the "sibling" server running on the port 26, you can redirect to the domain other-port if you put the following record into your Router table:

To relay mail to the "sibling" server running on the port 25, but on a different IP address 11.22.33.44, you can redirect to the domain other-ip if you put the following record into your Router table:

For example, if all mail to the domain client57.com should go to the sibling server running on a different port, place the following records into the Router:

or simply:

How can my customer servers receive mail if they have dial-up connections? (ETRN)

Small sites may have dial-up connections only and they can be off-line most of the time. To provide better mail delivery to those sites, you should use your CommuniGate Pro server as their back-up mail relay. You should:

• create 2 MX records (in your DNS server) for the customer domain.dom domain name: a high priority record pointing directly to the customer server and a lower priority record pointing to your CommuniGate Pro server;
• configure your server to let it relay mail to the domain.dom domain;
• optionally include the domain.dom name into the Hold Mail list of your CommuniGate Pro SMTP module;
• configure the customer server to send the wakeup ETRN commands to your server.

How can I hold all client mail till their servers send ETRN?

If your client has a symmetric dial-on-demand link (i.e. a link that is brought up by the provider when there is any traffic to the client hosts), that client may want:

• to get all mail via your server instead of receiving mail directly, when each incoming message brings the connection link up;
• to receive mail from your server only when the client software issues the ETRN command, so your server will not bring the link up and try to relay the client mail as soon as it is received.

To serve such a customer (the client.com mail domain), you should:

• create a DNS A-record for the mail.client.com name, pointing to the IP address of the client server;
• create a DNS MX record for the client.com domain pointing to your CommuniGate Pro server; you should NOT include the mail.client.com name into the MX records for the client.com mail domain.
• create a record in the CommuniGate Pro Router:
  client.com = mail.client.com._via
• include the mail.client.com name into the SMTP module Hold Mail for Domains setting.

How can my customer servers receive mail if they have dynamic IP addresses? (ATRN/PROP)

If a customer has a mail server and a dial-up connection with a dynamic IP address, the customer server cannot be listed in the DNS, because DNS records link domain names and fixed (static) IP addresses.

To deliver mail to those sites, you should configure your CommuniGate Pro server as their mail relay. Depending on the customer server capabilities, your can use either the ATRN or the Unified Domain-Wide Account (RPOP) method.

If the customer server supports the On-Demand Mail Relaying (ATRN) method, you should:

• create an MX record (in the your DNS server) for the customer domain.dom domain name; this record should point to your CommuniGate Pro server address;
• include the domain.dom name into the Hold Mail list of your CommuniGate Pro SMTP module;
• create the domain.dom account in your CommuniGate Pro server Main Domain and assign some password to that account;
• configure the customer server to send the ATRN command to your server using domain.dom as the login (AUTH) name and the domain.dom account password as the AUTH password. If the customer software cannot send the ATRN command, it may send the TURN command, but only after it sends the AUTH command with the proper name and password.

If the customer server supports the Unified Domain-Wide Account method, you should:

• create an MX record (in the your DNS server) for the customer domain.dom domain name; this record should point to your CommuniGate Pro server address;
• create the dd-customer account (actual name is not relevant) in your CommuniGate Pro server Main Domain and assign some password to that account;
• add the following record to the CommuniGate Pro Router:
  domain.dom = dd-customer.local
• configure the customer server to poll the dd-customer account on your CommuniGate Pro server;
• configure the customer server to use the X-Real-To header field (or other field you have specified in the Local Delivery module settings) as the "special header" containing the mail envelope information.

How can my customers release mail to all their domains with one ETRN or ATRN?

Remote servers that use your CommuniGate Pro server as a back-up mail relay can serve multiple domains. Those servers usually send ETRN or ATRN commands specifying only one domain as the command parameter.

To let mail to all customer domains being released with one ETRN or ATRN command, you should enqueue mail sent to the customer "secondary" domains into the customer "main domain" queue.

If the remote server should receive mail for the domain1.dom, domain2.dom, and domain3.dom domains, but it sends ETRN or ATRN commands only for the domain1.dom domain, use the following Router domain-level records:

Mail to all customer domains will be placed into the domain1.dom queue, and if you want to hold that queue till the ATRN/ETRN command is sent, include the domain1.dom name into the Hold Mail for Domains setting of the SMTP module.

How can I store all outgoing mail sent by all my users?

You may need to store all outgoing mail into a Mailbox in a system administrator or a security officer Account.

To copy mail sent from certain Domains, use a Server-wide Rule:

The account security should already exist in the main domain, and the Mailbox outgoing should already exist in that account.

How can I restrict to whom my users can send mail?

You may meed to let certain groups of users send mail only to other members of that group and/or to only certain addresses outside that group.

The simplest way to implement restrictions is to organize these groups of users into CommuniGate Pro Domains. If all users in the Domain dept1.company.dom (except the user boss) are allowed to send mail only to the users in the same Domain and to the supervisor@hq.company.dom address, then the following Server-wide Rule should be used:

How can I create and use Shared Mailboxes?

A shared Mailbox is a Mailbox in Account X that can be used by a user (Account) Y. Shared Mailboxes can be used for incoming mail processed by a group of people (sales department, support department, etc.). Shared Mailboxes can be used as an extremely fast and effective alternative to mail and distribution lists: the announce Mailbox in the marketing account can be used to store all company announcements. If all employees have read access to that Mailbox, a single copy of each announcement becomes available to everybody.

To use a Shared Mailbox, two steps must be taken: first, potential users of the shared Mailbox should be granted access rights for that Mailbox. On the second step the user mailers should be configured to access shared Mailbox(es). Since these shared Mailboxes belong to a different account, they are called foreign Mailboxes.

First, the owner of the shared Mailbox should create a regular Mailbox within his/her account. It is useful to create a special account public and create shared Mailboxes in that account. To grant others access rights to the shared Mailbox, the account owner should use either a decent IMAP client that can deal with ACL (Access Control Lists) or the WebUser Interface. The WebUser Interface section describes how you can set the desired Mailbox Access Rights.

If a shared Mailbox is created inside the public account, it is useful to grant all Mailbox Access Rights to the real shared Mailbox owner, so the owner can perform all operations with that Mailbox without logging in as the user public.

To access shared Mailboxes, user mailers should be configured to display both the user account's own Mailboxes, and the available shared (foreign) Mailboxes. The most universal method is to use the account Mailbox Subscription list. This list is a simple set of Mailbox names, and both account's own Mailbox and foreign Mailbox names can be included into that list.

Many IMAP clients can only use the Mailbox Subscription list, but they cannot modify that list, or they do not allow a user to enter a foreign Mailbox name into that list. In this case IMAP users should use the WebUser Interface to fill their subscription lists. If a shared Mailbox announce has been created in the account marketing, users should put the ~marketing/announce foreign Mailbox name into their subscription lists.

The domain administrator can use the Account Template to specify the initial Mailbox Subscription list, so all new accounts automatically get subscriptions to some shared Mailboxes.

When shared Mailboxes are included into the Account Subscription List, the users should configure their mail clients to display all Mailboxes listed in the Subscription List:

• WebUser Interface users should check that the Show All Subscribed Mailboxes Setting is selected.
• Microsoft® Outlook Express users should open the IMAP account Properties panel and enable the Advanced setting called Only Show Subscribed Folders. Since in this mode the Outlook Express mailer shows ONLY the Mailboxes listed in the account Mailbox Subscription list, the users should include their own Mailboxes (Sent, Drafts, etc.) into their Subscription lists.
• Netscape® Messenger users should open the IMAP Mail Server Properties panel and enable the Advanced setting Show only subscribed folders. Since in this mode the Messenger mailer shows ONLY the Mailboxes listed in the account Mailbox Subscription list, the users should include their own Mailboxes (Sent, Drafts, etc.) into their Subscription lists.
  The Messenger automatically scans the public account and displays its shared Mailboxes made available for the Messenger user. As a result, if all shared Mailboxes are created in the public account, Netscape Messenger users should not do anything with the Mailbox Subscription Lists.

Some clients (including Microsoft Outlook and Outlook Express) cannot display foreign Mailboxes even if those Mailbox names are included into the account subscription list. Users of these mailers can access foreign Mailbox via Mailbox aliases. They should use the WebUser Interface to specify aliases for foreign Mailboxes they want to access. If a shared Mailbox announce has been created in the account marketing, users should create the mkt-announce Mailbox alias for the ~marketing/announce foreign Mailbox. Their IMAP clients will display the mkt-announce name and will provide access to the ~marketing/announce Mailbox messages.

The domain administrator can use the Account Template to specify the initial Mailbox Aliases, so all new accounts automatically get a predefined set of Mailbox aliases for the specified shared Mailboxes.

How can an Administrator clean User Mailboxes?

Sometimes a Server or Domain Administrator should be able to check user Mailboxes to clean or file user messages. This can be done without actually logging to the Server under that user name.

The Server Administrator with the All Domains access right has unlimited access rights to all Mailboxes in all Accounts.
The Domain Administrator with the CanAccessMailboxes access right has unlimited access rights to all Mailboxes in that Domain Accounts.

Administrators can use any decent IMAP, MAPI, or XIMSS client to access user Mailboxes. That client should be able to let a user enter a Mailbox name directly.
To open the INBOX Mailbox in the username Account, administrators should log in under their own names and tell the client to open the ~username/INBOX Mailbox.

The WebUser Interface can be used for the same purpose. Administrators can log in under their own names, open the Subscription page and type the user Mailbox name in the Open Mailbox panel.

How can I redirect WebMail users from http:// to https:// ?

By Creating and Managing Skins copy the login.wssp file into login.wssi and replace the contents of the original login.wssp with the following code:

<!--%%IF secureChannel -->
<!--%%INCLUDE "login.wssi" -->
<!--%%ELSE -->
<HTML>
<HEAD>
<META HTTP-EQUIV=REFRESH CONTENT="0; url=https://%%domainName%%/">
<TITLE>Redirecting to the secure interface</TITLE>
</HEAD>
</HTML>
<!--%%ENDIF--> 

How can I provide username.domain.dom Personal Web sites?

The standard URL for the username@domain.dom Account File Storage is http://domain.dom/~username.

You may want to provide better looking http://username.domain.dom/ URLs for your Account personal Web sites. This feature is based on the method the Server uses to route requests sent to the HTTP User ports.

For users in the domain.dom secondary Domain, add the following records to the Router:

*.domain.dom = *@domain.dom
<LoginPage%*@domain.dom> = *@domain.dom

If the domain.dom is your Main Domain, then add the following records:

*.domain.dom = *@fict
<LoginPage%*@fict> = *

These records route the LoginPage@username.domain.dom addresses to username@domain.dom addresses (or username addresses if domain.dom is the Main Domain).

Finally, you should update your DNS server to ensure that all username.domain.dom names point to your Server IP address.
You may want to use wildcard records (*.domain.dom CNAME domain.dom) if your DNS server supports them.