The Transition

The Transition
	Stopping the IWInet mail service

Where to make changes

At the IWI, as can be seen in , iwi200 is the mail server. Its configuration is in the directory /etc/postfix and the files therein. Some of the lists used by postfix were sometimes published via NIS from /etc/mail/primary_mx_hosts/etc/postfix on iwi1, but this no longer seems to be the case. The most important files in either directory are aliases, and virtual.

	Note
	Please note that `aliases` often resides in `etc` instead of in `etc/postfix`.

The IWI MTA, PostFix, uses these two tables when delivering mail it considers itself the final destination for. In the case of virtual addresses, it looks up the address in the left hand side of the virtual table, and sends it on to the address(es) on the right hand side ^[48]. Once the address to deliver to is local (i.e. not virtual), the aliases table is used for the same sort of lookup.

Before being delivered, mail received by iwi200 is scanned for SPAM and viruses at iwi202. iwi202 Is also the Authenticated SMTP server. Mail received by iwi202 via ASMTP is not scanned, as the sender is known, and only IWI employees have accounts. iwi202 Is not going to feature prominently in this plan, since it will just become jobless when iwi200 is taken down.

Mail delivery at iwi200 is influenced on a per-user basis by ~/.forward^[49], and often also by ~/.procmailrc^[50]. If delivered without .forward or .procmail intervention, it will end up in /var/spool/mail/${USER}^[51], but procmail can also access home directories, and sort mail into boxes located there.

iwi200 Serves the mailboxes in /var/spool/mail via IMAP and POP. Via IMAP, the users' home directories can also be reached.

Figure 1. Sketch of current mail flow at the IWI

A sketch of the current mail flow at the IWI

Preliminary actions

Before the CIT mail server can start taking over iwi200's duties, a couple of things must be sorted out. Among others, we must know which IWI account maps to which RuG account, and we must have some replacement for the IWI mailing lists. The required steps are listed in

Procedure 79. Preliminary steps to be taken before moving the mail

Find a CIT address for every local IWI user.

List all addresses mentioned in virtual and aliases. Drop all addresses containing a “|” (pipe), drop all addresses iwi200 doesn't consider itself final destination for (i.e. addresses with “@”-signs, but outside the {iwinet,cs,math}.rug.nl domains.
Use the postalias command to peruse both lists for reducing each of the remaining addresses to a local user (i.e. an address with no “@”-sign in it).

For each of the remaining addresses, find the users' RuGmail address.

Note

Most of these users' RuGmail addresses can be found simply by looking in their .forward or .procmail files, where the forward we want to accomplish later is already set. For the other users, the secretaries (secretariaat@cs.rug.nl, secretariaat@math.rug.nl) will be able to provide so-called P-numbers if they know the users' actual name (as opposed to their username). In cases where this mapping from username to actual name is unclear, peter@cs.rug.nl will be able to clarify.

Create a lookup table with local IWI users on the left hand side, and RuGmail addresses on the right hand side. This is the IWI-to-RuGmail mapping

Warning

There is a category of IWI addresses that do not have RuGmail equivalents. These include a few former IWI employees as well as family members of IWI employees. To my knowledge, the University of Groningen doesn't serve IMAP to people in these categories. Inform them of their predicate, asking them to supply an address to forward to. If they provide it, put it in the list. If they don't, service to them will necessarily be dropped.

Move mailing lists away from iwi200

On iwi200, in aliases and virtual, find all simple lists, i.e. entries with a “,” (comma) in the right-hand colums, and all lists managed by slist or majordomo (which are easily recognized by the occurrence of these strings in the RHS column). For each list, find all the recipients.

	Note
	The recipients on `slist`-type lists can be found in `iwi200/home/slist<name-of-list>/dist` on `iwi200`. Lists maintained by the majordomo command have their actual list of addresses in `/var/lib/majordomo/lists/<name-of-list>` in `iwi200`.

For each of the lists, contact systeembeheer@cs.rug.nl to ask whether the list can be dropped or not.
For each of the remaining lists, contact the CIT helpdesk to ask for a list with the appropriate recipients on the CIT list server. If the list is going to have a new address, send notification to all recipients on the list.

Ensure correct mailflow from the IWI

Install and configure a very simple mail server that

accepts mail only from within the IWI domains^[52],

does no SPAM or virus checking,

does no local delivery, only forwarding, to the CIT mailserver,

has a mapping from local usernames to RuGmail addresses,

Ensure that local administration routines include adding an entry to this lookup table when creating a local account.

Make all IWI machines use this simple server as a smarthost.
Note

This has the advantage of bringing all potential local problems to a single machine, where they will be seen sooner. It also postpones the need for the IWI to use central accounts only.

Note

This smarthost is meant for machine-generated mail only. Human users should use either iwi200 or the CIT mailer for outgoing mail.

Redirecting the bulk of mail flow

The IWI SMTP server can largely be switched out of the mail circuit by setting the MX record for all domains owned by the IWI to point to the central SMTP server instead of the IWI smtp server. The steps to be taken are in .

Procedure 80. Steps to be taken in taking the IWI SMTP server out of the mail flow

Offer the virtual table as it is now to the CIT postmasters (possibly via the helpdesk), and wait for them to

make the CIT mailer accept mail for the IWI domains,
perform upon the addresses in those domains the address translations as specified in the table.

	Warning
	It may be against central policy to forward mail in the same way the IWI server does for local users with forwards to addresses outside the RuG. If that is the case, their mail may have to be stored in central mailboxes instead of keeping the forward. Notify them of that.

Moving the users' mailboxes, and adjusting their settings

We need to take down the old POP/IMAP server as well as the SMTP server, as they are of equal age and state. So the users' mail must be moved from the IWI mailboxes to the central mailserver. This is near trivial, as modern mail programs are able to open both accounts at the same time, and entire mail folders can be dragged from the old account to the new one. The only problem lies in forcing the users to actually move their mail. Best approach is probably to state a deadline, but offer support to those who con't trust themselves with the task. While we 're at it, the users must also be taught to use the CIT mailer for outgoing mail.

Procedure 81. Adjusting users' settings

Train two or three helpdesk employees to understand Linux mailers and the problem at hand.
Write and send out documentation telling the users that they should stop using iwi200 for outgoing mail, and start using the CIT mailer. Offer helpdesk to those who don't understand.
Write and send out documentation telling the users that they should move the content of the IWI mailboxes to their RuGmail accounts. Offer helpdesk for those who don't understand.

Over the course of a few weeks, watch /var/spool/mail on iwi200 grow thinner. Then, tar and gzip whatever remains, and send it to those who didn't clean up their mailboxes.

	Warning
	One could wish to ensure that no mailboxes were used in users' home directories any more either. This is done by turning off the `IMAP` and `POP` daemons, and waiting for complaints.

Cleanup of `iwi200`

Now that this is all done, we get to the situation as illustrated in . All that is left to be done is to watch the logs of iwi200 to ensure there is no mail coming in any more. If need be, the local users' @iwinet.rug.nl addresses can be put in the relocated table for a while before the service is finally turned off and we end up with . Turning off the ASMTP service at iwi202 has much lower impact, and can be handled separately.

Figure 4. IWI mail users now talking to CIT servers

A sketch of the mail flow at the IWI with users talking to CIT servers

Figure 5. Sketch of mail flow at the IWI with iwi200 off

A sketch of the mail flow at the IWI with iwi200 off

^[48]It does this over and over again until the resulting address occurs in the LHS no more.

^[49]if it exists

^[50]if that exists and is called from the .forward

^[51]MBOX-style

^[52]This prevents it from becoming an open relay too.

	Note
	This has the advantage of bringing all potential local problems to a single machine, where they will be seen sooner. It also postpones the need for the IWI to use central accounts only.

	Note
	This smarthost is meant for machine-generated mail only. Human users should use either `iwi200` or the CIT mailer for outgoing mail.

	Warning
	It is not yet time to turn off `iwi200`, because many IWI users still send mail via it, as can be seen in