Migrating to CommuniGate Pro

Users that access their mail accounts using any standard Internet Protocol (POP, IMAP) do not have to switch their mailer applications or change mailer settings - CommuniGate Pro supports not only the published mail access protocols standards, but most of unofficial protocol extensions, too.

One of the supported Mailbox formats supported by CommuniGate Pro is the BSD-type text mailbox format: a Mailbox is a text file with messages separated with an empty line and a line starting with the symbols From .

Since most legacy mail systems use this format, the existing mailbox files can be used when migrating to CommuniGate Pro. You should either copy the old mailbox files into the proper places in the CommuniGate Pro Account directories, or you can specify that some Accounts have Legacy INBOXes (see above), and the old mailbox files will be used "in place".

Note: when CommuniGate Pro stores a message in a BSD-type Mailbox, it adds additional fields to the separator (From) line. These fields are ignored by legacy mailers and mail servers, but they allow the CommuniGate Pro Server to keep the message status and unique message ID information. When you make your CommuniGate Pro Server use a BSD-type mailbox file composed with an old mail system, it issues warnings (Log records) about missing fields in the message separators. The Server still opens such mailboxes: it creates empty status flag sets for such messages, and it generates unique IDs on-fly. As users read, move, and/or delete old mail from their mailboxes, messages stored with the old mail system disappear, and the Server stops complaining when opening these mailbox files.

If your old mail server authenticated clients are using the Unix OS account and passwords (the passwd and shadow files), and you do have the passwd file from the old server, then you may want to enter the Unix-style (crypt-encrypted) passwords as the CommuniGate (internal) Passwords.

To make the CommuniGate Pro server process its internal password string as a U-crpt (crypt-encrypted) or other support encrypted password (see below), store the password in the Account Settings with one-byte binary 002 prefix. If you want to create a user test using the CLI interface, and the Unix (crypt-encrypted) password for that user is AslUzT1JkPsocc, then use the following CLI command:
createaccount "test" {Password="\002AslUzT1JkPsocc";}

If you create users by importing an account list from a text file, place the Unix passwords strings into the UnixPassword column, not into the Password column. In this case, the Loader will automatically add the binary 002 prefix to all password strings. If you create users using the LDAP Provisioning feature, specify the encrypted password as the unixPassword attribute.

Account Settings of the new accounts should specify one of the CommuniGate Pro password encryption methods (clear text or A-crpt). Users will be able to log in using their old Unix/encrypted passwords. When they update their passwords, new CommuniGate Password strings will be stored using the specified CommuniGate Pro password encryption method. All users that have updated their passwords will be able to use the secure SASL authentication methods.

Some servers produced by the Netscape and Software.com companies store user passwords using several encryption methods. When passwords are retrieved from those servers, they have the following form:
{method}eNcoDeD
or
$method$eNcoDeD
where method specifies one of the standard encryption methods, and the eNcoDeD string is an encrypted password (sometime - Base64-encoded).

CommuniGate Pro can use these passwords in the same way it uses the Unix-encrypted passwords, and they should be entered in the same way: you should use the binary 002 prefix in the CLI commands and/or you should place those passwords into the UnixPassword field of the Account Import file.

The following encryption methods are supported:

• {crypt} - the standard Unix crypt method.
• {WM-CRY} - the standard Unix crypt method (same as {crypt}).
• {MD5} - the MD5 digesting method (Base-64 encoded MD5 digest of the password string).
• {SHA} - the SHA1 digesting method (Base-64 encoded SHA1 digest of the password string).
• {NS-MTA-MD5} - the MD5-based method used in the Post.Office servers and old Netscape Messaging Servers (the eNcoDeD portion contains 64 hexadecimal digits).
• {SSHA} - the "salted SHA1" digesting method (Base-64 encoded SHA1 digest of the password and salt strings, followed with the salt bytes). This method is used in the Sun Directory Server application.
• {LANM} - the "LAN Manager" hash used in Microsoft Windows servers (the eNcoDeD portion contains 32 hexadecimal digits).
• {MSNT} - the "Microsoft NT" hash used in Microsoft Windows servers (the eNcoDeD portion contains 32 hexadecimal digits).
• $1$ - MD5-based password hash used in FreeBSD and some other Unix systems.
• $2a$ - BlowFish-based password hash used in OpenBSD and some other Unix systems.

The following is a sample Import file:

Name UnixPassword Password Type user1  YIdhkjeHDKbYsji Unix-crypt user2  {SHA}Ue4Erbim2TC7CmuukMOBejeytr2= SHA1-digested user3  {MD5}zverMUhsgJUIDjeytr2= MD5-digested user4  {crypt}YIdhkjeHDKbYsji Unix-crypt, same as for the user1 account user5  $1$VlPrB$vNjOAytB3W.j0bkkbaN2Z. BSD-type MD5-encrypted

You can use a CommuniGate Pro CLI script to automatically import all users and their passwords from the OS /etc/passwd file. See the CommuniGate Perl Interface site for a sample script.

If you are migrating from a sendmail-based mail system, you may find the following information useful:

The aliases file

The sendmail aliases file allows the administrator to redirect local mail to one or several addresses. Sendmail uses the term "alias" for too many different things, so you should select the proper CommuniGate Pro feature to implement different types of sendmail "aliases":

• Each account can have one or several aliases. Mail sent to any Account Alias name is routed to the Account itself. If the domain.dom Account john.smith has j.smith and smith aliases, mail sent to [email protected] and [email protected] addresses is delivered to the [email protected] Account. When an Account is renamed, its Aliases automatically start to point to the new name, and when an Account is removed, all its Aliases are removed, too.
• Domain Forwarder objects allow you to redirect mail sent to a Domain address to any other address. The domain.dom Forwarder susan.smith can reroute all mail sent to [email protected] address to the [email protected] address.
• Domain Group objects allow you to redirect mail sent to some Domain address to any set of addresses.
• The Router module allows you to redirect mail sent to a certain address to any other address. The Router Alias Record <*[email protected]> = [email protected] will reroute mail sent to [email protected] and to [email protected] to the [email protected] address.
• The Account Rules allow the administrator and/or the users themselves to redirect/forward/mirror all or certain mail to one or several addresses.
• The Server-Wide Rules allow the administrator to redirect/forward/mirror all or certain mail to one or several addresses.
• The shared or Foreign Mailboxes feature allows a user to grant access to a Mailbox to other users; in many cases a shared Mailbox is a much better alternative to mail distribution.
• The LIST module provides a very powerful mailing list distribution mechanism.

procmail processing

The Server-Wide, Domain-Wide, and Account-Level Automated Rules allow administrators and users to perform automatic mail processing and filtering using the powerful condition checking and processing operations built into the CommuniGate Pro Server.
For the situations where messages should be processed using an external filter or processor, the Execute Automated Rules operation can be used to start the specified external program as a separate OS task (for example, the Rules can be used to process all or certain incoming messages with the same procmail program).

The special Exchange Migration Utility allows you to retrieve user lists from an Exchange server and to create those users in CommuniGate Pro Domains. The utility copies all user folder data (mail, calendaring, contacts, etc.) converting data and address formats "on-the-fly".

The utility requires an MS Windows workstation to run.

If you have a list of account names and passwords you can copy the contents of the mail folders accessible via IMAP protocol from the Other Server by using the syncIMAPMail mail migration and synchronization utility.

If the passwords are not known then you can:

• authenticate as admin and specify the name of the account being copied via --proxyAuth option, if that IMAP extension is supported by the Other Server.
• authenticate as admin via PLAIN method and specify the name of the account being copied, if that authentication method is supported by the Other Server.
• reset the passwords to a known value.

Use this alternative migration method when the password switching method explained above cannot be used, and/or the user names and passwords cannot be retrieved from the old server.

The method is based on the External Authentication feature of the CommuniGate Pro server.

Download, install, and tailor the migration script, and configure CommuniGate Pro to use this script as the CommuniGate Pro External Authentication program.

Create the target CommuniGate Pro Domain, and enable the Consult External for Unknown Domain settings. In "Login Methods" disable all methods except PLAIN and SESSIONID to force users' mail applications to submit only unencrypted passwords. Disable the "Use CommuniGate Password" option and enable the "Use External Password option" in the Account Template.

When a user attempts to connect to a non-existent Account, or when CommuniGate Pro receives a message for non-existent Account, the External Authentication script is called. The script connects to the old server using the SMTP protocol and checks if the account with the same name (same address) exists on the old server. If the old server does not reject the address, the script creates the Account with this name in the CommuniGate Pro Domain. Then the CommuniGate Pro Server delivers the message to this newly created Account.

When a user connects to the CommuniGate Pro Server, the user mailer sends the user name and the user password in the plain text form. Because the CommuniGate Pro Account has the Use CommuniGate Password option disabled, and the Use External Password option enabled, the External Authentication script is called. The script connects to the old server using the POP or IMAP protocol and checks if it can log into the old server with the provided user credentials.

If the old server accepts the specified password:

• the script uses the CommuniGate Pro CLI:
  • to set the specified password as the CommuniGate Password for this Account,
  • to switch off the Use External Password option for this Account,
  • to switch on the Use CommuniGate Password option for this Account.
• the script starts the syncIMAPMail programs to copy the account mailboxes from the old server to the CommuniGate Pro server, or saves the name/password pairs into a text file which you can use later (this is a configurable option).

After the first successful login, the correct password will be set as the new CommuniGate Password, and all Account mail will be copied from the old server.

After all old server users have successfully connected to the CommuniGate Pro server at least once, all their Accounts will be created and have the correct CommuniGate Passwords set. Then you can disable the External Authentication script and retire the old server.

If Calendars and Contacts can be exported from the Other Server as text files in vCalendar and vCard formats respectively, then they can be imported via Importing Calendars and Importing Contacts in CommuniGate Pro WebMail interface.

Importing the data of multiple users can be automated via importCalendars.pl script from the Script Repository for CommuniGate Pro.

Very often it is essential to switch to the new server without any interruption in the services you provide.

If you install the new CommuniGate Pro server on the same system as the old mail server, you should:

• switch CommuniGate Pro IMAP service to port 144, so it will not interfere with your old server IMAP activity.
• Configure CommuniGate Pro and create Domain Aliases and/or full featured Secondary Domains.
• Create some test accounts in the main and secondary domains and check that you can log into those accounts using WebUser Interface.
• Check that you can send mail from those accounts using the WebUser Interface: mail to other test accounts in the created domains and mail to other servers should be delivered correctly.
• If you have an IMAP client that allows you to specify a non-standard port number, check that you can log into the test accounts on the IMAP port 144.
• Create tab-delimited file(s) with names, passwords, and other attributes of your existing accounts and use the Account Import feature to create all accounts on your new server.

All this can be done while your old server is still active.

Now, you should stop your old server activity by either changing its port numbers to non-standard values, or by disconnecting it from the external network.

Use the syncIMAPMail program to copy all messages from your old server to CommuniGate Pro.

When all messages are copied, change the CommuniGate Pro IMAP port number back to 143. Now CommuniGate Pro will operate as your mail server, without any interruption in the services you provide.

You may want to keep the old server running for several hours - in case its queue contained some delayed outgoing messages. Just check that the old server does not try to use the standard ports.

If you create several Secondary domains in CommuniGate Pro, you may want to move accounts from your old server(s) to a Secondary CommuniGate Pro Domain, not to its Main Domain.

In this case, you should add the NewName field to your account list file, and copy all names into that column, adding the @domainname string to each name.

If you use the IMAP protocol to move messages between the servers, you may use a simpler method:

• If the target domain has an IP address assigned to that domain, use that address in the mail copying programs: all non-qualified names provided on connections established with that address are interpreted as names in that domain. See the Access section for the details.
• If the target domain does not have an assigned IP address, temporarily assign the IP address of the main domain to that secondary domain. Move the messages, and remove the IP address from the list of addresses assigned to that domain.