[Mailman-Users] Migration to a new server: recommendations for testing the new Mailman server before changing DNS records; also how to avoid lost/bounced messages during change-over?

Mark Sapiro mark at msapiro.net
Fri Jul 5 04:49:53 CEST 2013

On 07/04/2013 11:58 AM, David wrote:
> Our sysadmin has the new Debian server set up, Mailman is installed and our
> lists are copied over. This new server does not yet have our domain name or
> IP address. We want to test the new setup before making those changes.
> I would appreciate some recommendations for how to do this testing. What
> mail functions can we test? (Our MX records don't point to the new server
> yet.) Afaik, we can't really test normal mail processing in advance of
> making the final cut-over (or can we?).

If the mail server on the new box thinks list domains are in its local
delivery space (mydestination in Postfix), you can just send mail from
an MUA on the local box configured to deliver via SMTP to the local MTA,
and it all should work except that mail from Mailman to local addresses
will be delivered to the new box instead of the current live box.

> Are there things in addition to
> changing /etc/hosts that I can implement on my computer for testing the new
> Mailman server? Any ideas or suggestions are appreciated.

Adding an entry for (IPv4) with the domain name should be
enough for a local web browser to access Mailman.

> Also, in terms of the actual cut-over, how can we avoid bounced or lost
> messages if it takes several hours to transition?

You need to stop the MTA on the old box so it doesn't accept mail that
won't get moved.

Then, during the transition before the IP is moved to the new box, mail
to the MTAs attempting to deliver to to IP will get a connection refused
or a time out; probably connection refused because nothing is listening
on port 25. This is a retryable error. Possibly the majority of MTAs
will retry for 5 days before giving up and bouncing the mail. Almost all
will retry for at least 24 hours. Only a pathological few will bounce
the mail within a few hours, although some may send a delayed DSN after
say 4 hours but keep trying.

> My plan is roughly something like this:
> First I will moderate any pending messages. Then I will stop mailman. At
> this point our sysadmin will do a final data migration. Then I will shut
> down the server.

If you stop Mailman before stopping the MTA, be sure that Mailman's
qfiles are migrated.

> I will do the IP swap at Linode. Then I will boot up the
> new server. I hope we can do all that within a window of about an hour. I
> appreciate any advice on this too.
> For reference, here are some posts I have read in preparation for this move:
> How do I move a list to a different server-Mailman installation. -
> Documentation - Confluence
> http://wiki.list.org/pages/viewpage.action?pageId=4030682
> Re: [Mailman-Developers] Upgrading from 2.0.10 to 2.1.b2
> http://www.mail-archive.com/mailman-developers@python.org/msg03127.html
> [Mailman-Users] migrating mailman lists
> http://mail.python.org/pipermail/mailman-users/2007-January/055208.html
> [Mailman-Users] migrating mailman lists
> http://mail.python.org/pipermail/mailman-users/2007-January/055211.html
> [Mailman-Users] export/import of lists
> http://mail.python.org/pipermail/mailman-users/2004-June/037086.html
> BTW, does anyone have an itemized check list of all files that need to be
> copied? The posts above are not 100% complete (afaik) because, for example,
> they don't consider that some apache config settings may be related to
> Mailman. In our case we have ScriptAlias /m/ /usr/lib/cgi-bin/mailman/ and
> related changes.

Many posts on this subject are not 100% complete because they are based
on a standard GNU Mailman installation of Mailman itself. They do not
address the issue of getting Mailman installed and working as you want
on the new server. As Stephen points out, this is highly dependent on
source vs. package install, which package and what things have been
locally tweaked.

>From the Mailman point of view, at least for a source install, the only
things that need to be moved are the contents of Mailman's var-prefix
directory which are the directories
$var-prefix/qfiles/ and

Everything else comes under the heading of making Mailman work on the
new server as opposed to migrating lists, archives, etc. from the old

This is further confused and complicated by the fact that various
packages split that into different places. For example, RedHat puts some
of these directories in /var/lib/mailman, but locks/ is
/var/lock/mailman/, logs is /var/log/mailman/ and qfiles is

> Furthermore, files like /etc/mailname are related to Mailman configuration.

I happen to know that this is a Debian package trick for providing the
group with which the MTA invokes the mail wrapper to the wrapper without
recompiling the wrapper (is there a similar one for the web server
group?), but I can't possibly know all these things for all packages
(See the FAQ at <http://wiki.list.org/x/OIDD>).

> If anyone has or can come up with an itemized, file-by-file, checklist, I
> would like to be able to offer that to our sysadmin. The only alternative I
> know is a trial and error approach to making sure we don't overlook
> anything, and I prefer to avoid that method (especially the "and error"
> part!).

If Mailman works on the new box, all you need to move is the mutable
data described above. There is one important

CAVEAT! The contents of the archives/public/ directory are symlinks. You
don't actually have to move them at all as they are rewritten as needed
each time a list is saved, but if you do move them, you MUST move the
symlinks, not the referent directories in archives/private/.

If you move the referent directories, that static structure will never
be updated and the 'pipermail' public archive URL will continue to show
the archive as of the move. The actual archive in archives/private will
be updated and the updated will be visible via the 'private' URL but not
via the 'public' one.

Also note that if you are using an MTA with manual Mailman aliases, you
need to move those too. This does not apply to Postfix with
Postfix/Mailman integration as in that case, Mailman's aliases are in
the $var-prefix/data/ directory.

Finally, after the migration, run Mailman's bin/check_perms to be sure
ownership and permissions are OK. It wouldn't hurt to run it on the old
box before the move to get a baseline (some packages tend to use
symlinks which check_perms was not designed to handle).

Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list