CommuniGate Pro: Help Me
Intro
Installation
SysAdmin
Objects
Transfer
Access
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo
HelpMe

This section lists the most common problems with the CommuniGate Pro installations, and it provides the suggestions that should help you to solve those problems.

WebAdmin

I have rerouted the Postmaster account and now I cannot log in as the Postmaster.

CommuniGate Pro applies routing rules not only to addresses in incoming messages, but to all addresses it processes. If you have rerouted the postmaster account to some other account abc, then all attempts to log in as the postmaster will cause the Server to try to open the abc account. If you provide the correct password (i.e. the abc account password), you will be able to log in, but you will have the access rights granted to the abc account, not to the postmaster account.

You still can log into the postmaster account even if the postmaster name is redirected to a completely different address. Use the following name instead of the postmaster name:

abcd@postmaster.local
This address is always routed to the account postmaster. Use the regular postmaster account password with this string.

For more details on the .local routing, check the Local Delivery Module section.

I have deleted the Postmaster account.

If you have deleted the postmaster account, stop the Server and start it again.

If the CommuniGate Pro Server does not find the postmaster account during the startup process, it creates a new one. Check the postmaster account files to get the new postmaster password, in the same way you used when you installed the CommuniGate Pro Server.

I have created a secondary Domain and now I cannot log into WebAdmin.

When you connect to CommuniGate Pro via a browser, the Server checks the domain name you have specified in the browser URL. If that name matches the name of one of your Secondary Domains, the WebAdmin Interface of that Domain is opened, rather than the Server WebAdmin Interface.

To open the Server WebAdmin Interface, use the Main Domain Name in your browser URL. If that name does not have a DNS A-record or its record points to a different server, use the Server IP Address in the browser URL.

If all Server IP Addresses were assigned to secondary Domains, you can try to use ANY domain name that points to the CommuniGate Pro Server, and does not match any of the Secondary Domain names.

When I try to log in, I get the "access from your network is denied" error.

You have selected the Grant Access to Clients Only option on the Protection page. Now you can connect to the Server only from the addresses listed in the Client IP Addresses field (on the same page). If that field was left empty, you still can connect to the Server if you launch your browser on the Server computer itself, and connect locally.

If you have not entered anything into the Client IP Addresses field, or if you cannot connect from the IP Addresses listed in that field, then:

SMTP Receiving

My Server does not accept mail from my Web script/applet.

When the SMTP module receives messages, it tries to route the address specified in the Mail From command (the message 'Return-Path' address). If the domain name in that address is a name of the Server local Domain and the specified Account (or other Object) is not found in that Domain, the Router returns an error code and the SMTP module refuses to accept the message.

You should reconfigure your script/applet to use either an empty Return-Path (<>) for generated messages, or to use an E-mail address of some existing Account. If the script/applet cannot be reconfigured, you can create an Alias for any existing Account.

If, for example, your script/applet submits messages to your server with the <webform@mydomain.com> Return-Path address, and you do not have the webform Account in the mydomain.com Domain, you may want to create the webform alias for the postmaster Account. If delivery of a submitted message fails, the error report will be sent to the postmaster Account.

SMTP Sending

My Server cannot send mail to some host using SSL/TLS.

When the CommuniGate Pro SMTP module connects to a mail host/relay and tries to establish a secure (SSL/TLS) connection, it receives the host Certificate and check the name in that certificate. That name should match either the name of the domain the mail should go to, or the MX relay name for that domain.

When a remote server hosts several domains on the same IP address, it always sends out only one certificate, because the server cannot learn to which domain the incoming messages will go to and thus it cannot present the Certificate for that particular domain. As a result, your (sending) server may refuse to proceed.

If the server mainhost.com also hosts client1.com and client2.com domains, and the MX records for all 3 domains point to the same name and to the same IP address on that server, the server will always present only one Certificate - usually, the mainhost.com Certificate.

To allow your CommuniGate Pro server to send mail securely to client1.com and client2.com domains, you should specify 2 Domain-level Router records:

client1.com = client1.com@mainhost.com.smtp
client2.com = client1.com@mainhost.com.smtp

These records will place mail to client1.com and client2.com domains into the mailhost.com SMTP queue. You should place the mainhost.com name into the Send Encrypted list of the SMTP module, and the server will connect to the mailhost.com server, check its certificate (it should contain either the mailhost.com name or the name of the relay the SMTP module connected to), and then the SMTP module will establish a secure (SSL/TLS) connection with that server and it will send mail to recipients in the client1.com and client2.com domains via that secure connection.

Access

WebUser connections return the pink page saying "we do not provide Web Access to this domain"

It is very important to understand that the domain name something.com and mail.something.com are completely different domain names. If your CommuniGate Pro Server has the main domain mycompany.dom, and you are trying to connect to it by typing http://mail.mycompany.com:8100 in your Web browser, you will get the page saying that the CommuniGate Pro Server does not provide access to the mail.mycompany.com domain.

In most cases, you want the domain names mail.mycompany.com, webmail.mycompany.com, etc. to be just other names (aliases) of the mycompany.com CommuniGate Pro Domain. To specify this, open the mycompany.com Domain Settings page and find the Aliases table. In an empty field, enter the mail.mycompany.com name and click the Update button. Now the CommuniGate Pro Server will know that mail.mycompany.com domain name is just a different name for the mycompany.com Domain it serves. Connection requests specifying the mail.mycompany.com domain name will connect to the mycompany.com CommuniGate Pro Domain, and messages sent to a username@mail.mycompany.com address will be delivered to the account username in the mycompany.com domain.

Note: The WebAdmin interface defaults to the main domain if the name specified in the browser URL is not a CommuniGate Pro Domain name. This is why connections to the WebAdmin port (8010) can work, while the connections to the WebUser port (8100) return the "pink page".

WebUser sessions are disconnected almost immediately after login.

When a user connects to your server via a "multi-homed HTTP proxy" (used by large ISPs such as AOL), TCP connections come to the CommuniGate Pro Server from several different IP addresses of those proxy servers. If the Require Fixed Network Address option is enabled in the Account WebUser Preferences, user browser connections can be rejected. Disable the Require Fixed Network Address option for those users that connect via "multi-homed proxy" servers. If most of your users connect via those proxy servers, you may want to disable this setting in the Domain Account Defaults or in the All-Server Account Defaults.

Directory

Microsoft LDAP (Outlook and Outlook Express) users cannot find Directory records.

Most of LDAP clients (including the Microsoft Outlook products) contain a setting specifying the Directory subtree that should be used for search operations. In Outlook Express, this setting can found in the Directory Account Properties, on the Advanced stub. It is called Search Base and it should contain the DN for the user domain (by default, that DN is cn=domainname).

If this setting field is left empty, Outlook products silently replace it with the c=country_code string, and search operations fail (unless your Directory has the c=country_code subtree).

If you do want to search the entire Directory with an Outlook product, enter the word top into the Search Base setting field.

Attempts to update Account Settings result in the directory record with the specified DN is not found error.

This error appears when the Directory Integration option is enabled. This option tells the CommuniGate Pro Server to update the Account record in the Central Directory every time the Account Settings are updated. If the Directory does not contain a record for that account, the error message is returned. Account records may be missing in the Directory if the Accounts were created when the Directory Integration option was disabled.

To fix the problem, open the Domain Settings and find the Directory Integration panel. Click the Delete All button. It will remove all Domain object records from the Directory. Then click the Insert All button. The CommuniGate Pro Server will create a Directory record for the Domain, and then it will create Directory records for all Domain Objects (Accounts, Groups, Mailing Lists).

Note: if the Domain contains more than 100,000 Accounts, the Insert All operation can take several minutes.

Date and Time

Time stamps in messages sent or received with CommuniGate Pro are several hours off.

This problem is caused by an incorrect Time Zone setting on the server and/or on the client machines. To check the Time Zone setting value on the server machine, open the General page in the Settings realm of the CommuniGate Pro WebAdmin Interface. The Server Time field should contain the correct Date and Time values and the correct Time Zone value: -0800 means '8 hours behind the GMT', +0800 means '8 hours ahead of GMT'.

If the Time Zone value is incorrect, fix the OS settings that specifies that value, and re-open the General page to verify the Time Zone value.

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