The Transition
Prev Stopping the IWInet mail service Next

The Transition

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]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[46]. 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[47], and often also by ~/.procmailrc[48]. If delivered without .forward or .procmail intervention, it will end up in /var/spool/mail/${USER}[49], 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 76.  Preliminary steps to be taken before moving the mail

  1. Find a CIT address for every local IWI user.

    1. 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.

    2. 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).

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

      [Note]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.

    4. 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]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.

  2. Move mailing lists away from iwi200

    1. 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]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.

    2. For each of the lists, contact systeembeheer@cs.rug.nl to ask whether the list can be dropped or not.

    3. 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.

  3. Ensure correct mailflow from the IWI

    1. Install and configure a very simple mail server that

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

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

      [Note]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]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 77.  Steps to be taken in taking the IWI SMTP server out of the mail flow

  1. Now that the above has been completed, the mailing lists in aliases and virtual are superfluous. Comment them out, put their addresses in the relocated table along with their CIT counterparts, and have PostFix reload its tables.

  2. All users must be warned that mail that used to end up in their IWI mailboxes is going to be redirected to the central mail server. Particular stress must be put on the fact that they should not forward mail from central accounts to the IWI servers any more. It must also be communicated to them that server-side mail sorting will end.

  3. Use the IWI-to-RuGmail-mapping to rewrite the right hand side of virtual (and aliases, if applicable) in such a way that no entry redirects to local users any more. Have PostFix reload its tables.

  4. Make the users' mail files in /var/spool/mail read-only, and put a tail on /var/log/mail to see whether PostFix has trouble. It shouldn't. The mail flow is now like in .

    Figure 2. Sketch of mail flow at the IWI with all forwards in place

    A sketch of the mail flow at the IWI with all forwards in place

  5. If possible, try to make aliases empty by this time, with all translations done in virtual.

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

    [Warning]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.

  7. Test the new recipients on the CIT mailer, or have the postmasters test them, and verify that they work.

  8. Once the previous steps are completed, the MX records of the IWI domains and all machines on them must be set to point to the central SMTP server. This will lead to a rapid decline of the mail flow to the IWI servers, and a proportional increase of the flow to the central SMTP server.

    [Warning]Warning

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

    Figure 3. Sketch of mail flow at the IWI with MX records redirected

    A sketch of the mail flow at the IWI with MX records redirected

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 78.  Adjusting users' settings

  1. Train two or three helpdesk employees to understand Linux mailers and the problem at hand.

  2. 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.

  3. 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.

  4. 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]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


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

[47] if it exists

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

[49] MBOX-style

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

Prev Up Next
The new situation at a glance  Home Using NCPMOUNT to access central storage