Recipe 2.8 Migrating Ex-Users to New Addresses

Problem

You have been told to gracefully migrate ex-users to their new delivery addresses.

Solution

Add the redirect feature to the sendmail configuration using the following FEATURE command:

 dnl Notify senders about discontinued addresses FEATURE(`redirect') 

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail , and restart sendmail, as described in Recipe 1.8.

Add an entry to the aliases text file for each ex-user. The alias field of the entry is the local username where the ex-user previously received mail. The recipient field is the user 's new email address with the string .REDIRECT appended to the end of the address.

As always, when the aliases file is updated, run the newaliases script:

 #  newaliases  /etc/mail/aliases: 45 aliases, longest 30 bytes, 670 bytes total 

Discussion

The first two steps in the Solution section create a sendmail configuration containing the redirect feature. Of course, if your configuration already contains that feature, as does the generic Linux configuration described in Recipe 1.8, you can skip those first two steps and go right to creating the aliases.

As an example, let's assume we want to gracefully handle mail for an ex-employee for six months. Michael recently left the company. Proper customer relations is the first and most important step in transitioning Michael's mail. Jay has taken over all of his customers, and we now want those customers to send their business communications to Jay. During Michael's last week in the office, he took Jay to visit all of his local customers, and used conference calls to introduce Jay to all of his remote customers. The customers have been notified, and the business mail should flow to the right destination. If management drops the ball on customer relations, there is very little that a sendmail administrator can do about it. However, you can make sure that Michael gets his personal mail by adding an alias to forward the mail to his new address:

 michael:                 [e-mail] 

Michael is sent monthly reminders that his mail forwarding account will be closed in six months. Six month after his departure , the michael alias is edited as follows :

 michael:                 [e-mail] 

At first, Michael's mail is forwarded to his new address, as this -bv test shows:

 #  sendmail -bv [e-mail]  [e-mail]... deliverable: mailer esmtp,    host new.job.ora.com, user [e-mail] 

Forwarding, however, should not go on indefinitely. As long as the mail gets through, there are a certain number of senders who will not update their address books. At some point you must cut them off and stop forwarding the mail. In the example, we have a small site and are willing to forward mail for six months. A larger site might not want to do any forwarding at all.

At the end of six months, the .REDIRECT pseudodomain is added to the alias to terminate forwarding. The effect of the .REDIRECT pseudodomain can be seen in a sendmail -bv test:

 #  sendmail -bv [e-mail]  User has moved; please try <[e-mail]> 

Mail addressed to michael is now returned to the original sender with an error message that tells the sender to try Michael's new address. The mail is not forwarded, but the sender is told how to deliver the mail directly.

.REDIRECT is clearly not a valid domain name . In sendmail parlance it is a pseudodomain . Pseudodomains are listed in class $=P , and sendmail does not attempt a DNS lookup for any domain listed in class $=P . Pseudodomains are used to signal special processing. However, simply adding REDIRECT to class $=P is not enough. The redirect feature must be included in the sendmail configuration for the .REDIRECT pseudodomain to be handled in the manner described in this recipe.

Alternatives

Simply removing an ex-employee's account is a popular and viable alternative for migrating ex- employees off of your mail system. This alternative was rejected for the example problem because Michael is a sales person. We depend on sales for the survival of our business and did not want to alienate and confuse customers with a "User unknown" error when they attempted to reach their sales representative. For this reason, the solution emphasizes customer relations. However, if Michael had been a programmer working on internal projects, removing his account without any gentle migration may have been acceptable.

Another tempting alternative solution is to place the following alias in the aliases database:

 michael:         jay 

Jay has replaced Michael. This alias would forward all of Michael's mail to Jay. However, we rejected this alternative. If this alias is used, Jay receives unwanted mail from all of the remote mailing lists that Michael joined as well as Michael's personal mail, such as the invitation to Michael's high school reunion. We want to maintain a friendly relationship with Michael, so we can't just discard his mail. At the same time, Jay should not be obligated to forward Michael's mail. We chose to use the redirect feature. But these choices are a matter of policy that should be reviewed with management.

See Also

The sendmail book covers the redirect feature in Section 4.8.39.