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:
For more details on the .local routing, check the Local Delivery Module section.
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.
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.
If all Server IP Addresses were assigned to secondary Domains and all DNS domain names pointing to your server are names of your secondary Domains or secondary Domain Aliases, then use the following URL:
If the Client IP Addresses field was left empty, you still can connect to the Server if you launch your browser on the Server computer itself, and connect locally, using the http://127.0.0.1:8010 URL.
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, and you cannot connect to the server locally, using the http://127.0.0.1:8010 URL, then:
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.
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:
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.
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".
Usually, the Main Domain has the IP Addresses setting set to "All Available", so all addresses not assigned to secondary domains are automatically assigned to the Main Domain. If none of your Domains has the IP Addresses setting set to "All Available", then some of your server IP addresses may be not assigned to any Domain.
When a user connects to the server using a POP or IMAP client and provides just the account name (without the domain name), or when a secure (SSL/TLS) connection has to be established, the CommuniGate Pro Server takes the local IP address the user has connected to and tries to find the Domain that address is assigned to. If that IP address is not assigned to any CommuniGate Pro Domain, then the "unassigned local network address" error is generated.
Open the WebAdmin Settings->General page to see all the Local IP Addresses of your Server. You may have to click the Refresh button to see all addresses. The unassigned addresses are dispalyed in red.
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.
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.
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.
If you use RBL servers, you may want to restrict the DNR module Log Level to Major & Failures events only.
Other applications (servers, browsers, etc.) use the same type of sockets to resolve domain names, but they usually open and close those UDP sockets quickly, so you may not notice them in your netstat output. CommuniGate Pro opens the DNR UDP socket when it starts, and uses that socket for all DNR requests, closing the socket only when the Server shuts down.
On most platforms, CommuniGate Pro software installer does not replace the legacy sendmail program, though the package does contain the sendmail replacement program. In order to use that program, you should modify your Perl script: you should find all references to the sendmail program (usually the default path used is /usr/sbin/sendmail), and replace them with the {application directory}/sendmail references.
For example, if CommuniGate Pro and your CGI are installed on a MacOS X system, where the CommuniGate Pro application directory is /usr/sbin/CommuniGatePro/, the CGI script /usr/sbin/sendmail strings should be replaced with the /usr/sbin/CommuniGatePro/sendmail strings.