User Tools

Site Tools


old:classic:mail_system_migration_2009

Mail System Migration 2009

Outdated page.

Updated information at: Classic Linux.

Also please see: https://discourse.rahul.net/.


In the near future, the classic_linux environment will go through a mail system migration. (This migration will have no effect whatsoever on accounts in the directadmin environment.)

This migration will occur in stages as described below. None of these stages are yet in effect.

(Update. Stage 1 is now in effect.)

If you have never created or edited a .procmailrc file in your home directory, then this migration should be largely transparent to you, except for a change in SMTP authentication described under Stage 1. (But please see the “Common Problems” section near the end of this document.)

However, if you use a .procmailrc file for mail filtering, then you must keep yourself aware of the details of the migration as described below and make changes as described below. Otherwise, you might lose some or all of your incoming mail.

Note: Also please see 2009-10-15 Discontinuing Wildcard Domains which describes a concurrent change in mail handling, although that it not a part of this migration.

Diagnosing and Reporting Problems

During critical steps in the mail system migration, we will switch the mail system into a mode where all failures are treated as temporary, causing mail to remain queued, either at the sending site or on our machines.

If you do not receive mail that you were expecting, and if you are sure that the sender really did send it, please report the problem but don't panic—the mail is likely in the queue waiting to be delivered. Before you report a problem, please use the scan.logs command to check to see if the mail arrived and was rejected for some reason.

The best way to report mail problems during the migration is to do one (or both) of the following

In your problem report please include any available diagnostic information, e.g., copies of error messages and bounced mail headers. Please see our page:

It will tell you what type of diagnostic information should generally be included.

(You can also send mail to support@rahul.net, but this might not be practical if you are reporting a mail problem. However, you may be able to send mail to us via classic_linux_webmail even if your own mail client does not work.)

If you don't get a response sufficiently quickly, please call us at 408-293-9706 and leave a detailed message, including a reference to the already-filed written problem report, and a callback number. Phone calls should be used only to escalate problem reports already filed via trouble-ticket or by posting in the local newsgroups.

While you are waiting for the problem to be corrected, you can use our webmail interface at classic_linux_webmail to access your mail.

Migration Stage 1

(Begins Tuesday, October 13, at around 1:00 pm.) See Updates below.

When Stage 1 comes into effect, incoming mail will be delivered by two new machines. These are:

Each machine will deliver mail by default into your old inbox.

(See mailbox_changes for a description of old and new mailbox formats.)

Your procmail script .procmailrc if any will execute on either of these two machines when incoming mail arrives.

At this stage, you should take steps to verify that your procmail recipes execute correctly on these newer machines. All typical simple procmail recipes should require no change. If you are doing something complicated and/or machine-dependent in your .procmailrc file, you might need to make adjustments.

Incoming IMAP connections (made to imap.rahul.net) and POP3 connections (made to pop.rahul.net) will reach either of these two new machines.

These new machines will no longer do pop-before-SMTP for identifying you as a customer, so you will need to reconfigure your POP or IMAP client to use authenticated SMTP on port 587. For details of available ports and methods, please see the page ports_and_protocols.

Updates. 2009-10-13 5:30 pm. Stage 1 began as scheduled. So far as we can tell, all mail is being delivered normally. We will continue in Stage 1 until further notice.

Migration Stage 2

(Will be announced 1-2 weeks ahead of time.)

During Stage 2, there will be no machine changes.

The only changes will be done by you.

Before Stage 2 ends, you will need to revise your .procmailrc file to deliver mail solely into mailboxes in your home directory, and never into your old inbox. These mailboxes in your home directory can be in either the old mbox format or the new Maildir format. Instructions for doing so are already on our procmail page. You can deliver mail into your new inbox or into any other mailbox anywhere in your home directory tree as you prefer. (Update. Mailboxes that reside outside your Mail or Maildir directory might not be accessible via IMAP or POP. We recommend that all procmail recipies deliver mail either into your Maildir inbox, or into a subfolder with Maildir, or into an old-style folder within Mail.)

(See mailbox_changes for a description of old and new mailbox formats.)

Once you do this, there will be nothing reaching your old inbox. Your mail will become inaccessible via IMAP or POP3 connections to the default server names (imap.rahul.net and pop.rahul.net). However, you will be able to use IMAP or POP3 by connecting directly to the new machines oxygen.rahul.net and helium.rahul.net.

If your procmail recipes are not properly revised, and if they still cause any mail to be delivered into your old mailbox, then that mail will be lost when we reach stage 3.

Migration Stage 3

(Will be announced about 1-2 weeks ahead of time.)

Incoming mail will be delivered by two different newer machines. These are:

Each machine will deliver mail by default into your new mailbox, which resides within your home directory.

Your procmail script .procmailrc, if any will, execute on either of these two machines when incoming mail arrives.

If you have correctly revised your procmail recipes in Stage 2, then they should continue to work unchanged. Simply verify that everything is working correctly.

New Folders Test. To test the new mailbox and mail folder layout, you can point your POP or IMAP server to either of the machines listed above. Also, you can test the working of Squirrelmail in this new scheme by logging into a test installation of Squirrelmail at https://squirrelmail-new.rahul.net/sm/src/. You may need to re-initialize the folders seen by this test Squirrelmail by following the instructions on the squirrelmail instruction page.

Migration Stage 4

This will be just an optimization stage.

We will provide you with instructions on how to optimize your .procmailrc script to take advantage of features available only on the newer machines for more efficient processing of incoming mail. Primarily, these instructions will show you how to have your mail delivered by procmail into your mailboxes such that your mailbox is automatically indexed for fast retrievals and searches.

Common Problems

Can't send outgoing mail. This is most likely to happen if you have not enabled SMTP authentication in your mail client. Please see: ports_and_protocols.

Can't find folders. The new IMAP server by default looks for your mail folders within your Mail subdirectory (for old-style folders) and in your Maildir subdirectory (for new Maildir-style folders). In most cases your mail folders will already reside there. If you cannot find a mail folder that you know used to be there, try to enter the name of the folder in a suitable place in your mail program (rather than selecting it from a menu).

If you still cannot find a mail folder, please report the problem to us following the problem-reporting procedures given earlier in this document. We will fix the problem for you.

old/classic/mail_system_migration_2009.txt · Last modified: 2021/01/30 02:44 by admin