Ok, so as promised in my last post, here is a step-by-step guide on changing an email address. While it would be nice to think that this post will help several people solve similar problems, this post is also self-serving in that it will serve as a reminder in what I need to do should a similar situation arise in the future. However, before I get started, I want to explain a few things. First of all, for those who don’t know already, my server is running Linux: more specifically, Debian. As for background into the situation, I am the only user of this server but I do have several different user accounts on the system.

Note: I am using a Debian system and the examples here reflect that. However, I see no reason why most of the stuff here would not apply to nearly any Linux system. Also, I make no guarantees as to the functionality and performance of the methods described here. This is what I did and it seems to be working pretty good, but I cannot make any guarantees as to how it will work for you.

When I originally set-up this system, I was quite unfamiliar with different ways to setup and operate an email server. As a result, I am using Courier (which seems to be one of the best) for the backend, and am using the configuration where email accounts and users mirror each other. Each “user” then has their mail delivered into a folder in their home directory that is specified for such use. Back when I was getting this site launched and setting things up, I just wanted it to work and be moderately secure and didn’t really know much about it. I simply created seperate users for each email account I wanted (i.e. one for blogging, one for radio stuff, one for facebook, etc) to try and help keep myself organized and once it all worked, I didn’t worry about it.

However, I came upon a situation where the name (and corresponding email address) for one of my accounts was no longer accurate/current and I needed/wanted to change/update it. In thinking about this process, I came up with the following requirements for myself in doing this:

1. Change the name/identifier on the account so that all existing email would be unaffected. This would make it so I would be using a new username for logging in and email would have to be sent to a different address, but aside from that, it would be business as usual and all existing messages would be in the “new” mailbox because it would really be the old one with a new name.

2. Be sure that any email sent to the old address would be forwarded to the new address so that I wouldn’t miss any important messages that were sent.

3. Set up an autoreply so that if someone sends an email to the old address, they will get a response alerting them that the address has changed (and what it has changed to) as well as assurance that the message they sent has been forwarded.

In order to figure out what all needed to be done, I simply focused on one part of the situation at a time and figured out how to do that. After I had that figured out, I changed things back and worked on the next one. After having all three things figured out, I put them all together and actually made the change.

The first part was easy, to change an email address on a system set-up like mine, all that really needs to be done is to change the username used to log-in to the account as this is also the email address.

usermod -l <new username> <old username>

However, since I wanted to completely change the “user” and everything about it, there were a couple of other steps that needed to be taken:

- edit the file /etc/passwd to reflect the changes (change the email address listed for that user to the new one and also set the home directory to reflect the new username as well)
- rename the home directory from the old username to the new one

At this point, the email address has been changed, the new one must be used to log-in, any place that referenced the old username should now reflect the new one. However, as of running the usermod command, any mail sent to the old email address will no longer be delivered as that user no longer exists.

In order to be sure to keep receiving email sent to the old address, an alias needs to be set up. Again, a pretty simple process for someone who knows what they are doing (or is reading this post) but not something that is quite intuitive. In my setup, there is a directory /etc/courier/aliases/ and by default there is a file named ‘system’ inside that directory. Since I didn’t want to mess with anything that is already there and working, I simply created a new file ‘mine’ inside this directory (there is no extension with these files) and put my new setting inside it.

There is only one line of text needed in this file at this time, but more can be added later:

<old username>:<new username>

Save and close the file and you’re good to go…almost. In my testing of different things making sure I knew what I was doing and that this was going to work, I had a couple of times where I made a change to this file and it had no effect on my results. The reason? After modifying this file, you need to run the command:

makealiases

This will cause all files in the alias directory to be read, processed, and take effect. Make sure you do that or else it will not work, trust me on this. Now, you’re email address is changed, but all email sent to the old address will be automatically delivered into the mailbox under the new address. From here, the only thing left to do is to let people know that the email address has changed. Since I’m not a fan of using mass emails for this purpose, my thought is to tell people when they send a message to the wrong address.

This part got a little tricky, and caused the brunt of my frustrations with this project. The first thing you need to do is check the Courier configuration (on my system this is /etc/courier/courierd) and check the DEFAULTDELIVERY settings. For whatever reason, this was originally set to ./Maildir which basically means that courier takes the message and just delivers it with no additional processing. However, in order to set the autoreply, I changed it to maildrop by simply commenting out the original line and adding a new one like in the example below:

#DEFAULTDELIVERY=./Maildir
DEFAULTDELIVERY="| /usr/bin/maildrop"

This is the only change that needs to be made to that file and after making the change, save and close it. Then, restart Courier so that it will reload the configuration and your change can take effect. I also want to note that this step only needs to be done once. Next time you go to change an email address or setup an autoreply, the configuration will already be set correctly and you won’t have to worry about it.

The only thing left to do at this point is actually the part that took me the longest to get figured out. In setting up the autoreply, we are going to use two files. The first is the .mailfilter file (yes, it’s like having no filename but a mailfilter extension - this is similar to the .htaccess file that many of you are already familiar with) where you can set up several different rules for handling email. It’s a really powerful tool and I can already think of a few uses for it beyond what we are doing here. The second file we are going to need is a file with a name but no extension that will contain the content for the body of the email that will be sent in reply. For our purposes here, I’ll call this ‘message’.

Some really good documentation and explainations for ways to use the .mailfilter file can be found here, but I think of that as more of a reference and think I learned more from looking at some examples of using it. To keep the .mailfilter file simple and small, I am taking advantage of and using the mailbot utility.

Here is a slightly modified version of my .mailfilter:

if (/^To: *<old email address>@romandock\.com/)
{
cc "| mailbot -t <absolute path of message> -s 'New Email Address'"
}

In the example above, <old email address> has been substituted for the actual email address that I replaced. Also, <absolute path of message> refers to the location of the ‘message’ file. For example, this might be /home/<user>/message but it can be titled whatever you wanted to be titled as long as the file name matches what you call for in the filter. Finally, my example sets the subject to read: New Email Address anytime someone gets sent an autoreply. For the message file, just use a plain text file and type into the file as if you were typing the body of an email since that is where this file will be used.

Finally, in order to make this work right, maildrop is very particular about the .mailfilter and some of it’s properties. First of all, it cannot have any group or global permissions. This means that the owner should be the only one allowed access. This translates to an octal setting of 600 which gives the owner read/write access and nobody else has any access at all. The other thing to be sure of is the ownersip of the .mailfilter as it must be owned by the user whose account it is in. You may have to do the following:

chown <user> .mailfilter
chgrp <user> .mailfilter

or

chown <user>:<user> .mailfilter

That last part is very important and should not be forgotten as the two minor things (.mailfilter permissions and ownership) we just discussed (along with not reading logs) cost me a considerable amount of time.

There, that wasn’t so hard, was it? Now, just log in to some other email account and send yourself a few test messages. Send 1 or 2 to the old address and 1 or 2 to the new address. For the ones you send to the old address, you should receive your autoreply in response relatively quickly. For the ones you send to the new address, you shouldn’t receive the autoreply. Also, log in to your “new” email account and make sure that all of your test messages came through regardless of what address they were sent to.

Ideally, all tests were successful and everything worked as intended. If something doesn’t work right, never underestimate the power of a .log (which for me is /var/log/mail.log) and go from there.

I hope this post was helpful to someone besides myself, but even if it’s not, I’m sure I will be referring back to it at least a couple of times in the future so it’s not a total waste.