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.

I didn’t have a post yesterday because when I should have been writing that post, I was too busy racking my brain and banging my head against the proverbial wall. You see, I was making what I thought would be a relatively simple change to my server and changing one of my email addresses to something else. In retrospect, it’s really not that big of a deal and I will detail the process in my next post.

However, while working on this, things were not going as smoothly as they should have. I’m sure this is partially due to my never having done this before, but it still shouldn’t have taken me as long as it did. There was one particular part of the process that did not seem to be working right and I couldn’t for the life of me seem to figure out why it wasn’t doing what it was supposed to do.

After reading through tons of documentation on the subject, and running multiple Google searches during which I wasn’t even exactly sure what I was searching for, I was at a loss for what to do. By some random chance, one of my searches led me to a forum discussion and one of the entries made reference to the mail.log file. At this point a light bulb came on in my head. Duh! Of course, I should look in the log and see exactly what (if anything) is going on that my changes are not having any effect!

Now, I already knew about log files and have used them many times in the past to help troubleshoot and solve issues, but for some reason I never thought to check it this time around, perhaps because I’d never made use of this particular one before. So, after opening mail.log and going directly to the end of the file, I found an error message. I was happy to see this. Most people (myself included) don’t like error messages because we don’t like getting errors and they mean something is wrong. In this case, I was glad to see them because I already knew something was wrong but now I could figure out what and knew what I was looking for.

From here I was able to Google the error message, find a couple of notes on the topic, and implement a fix. Then, test, check for success and the go to the log to find the next error message and repeat. While there were a few other forces at work that slowed my success, I’m sure that I would have saved a fair amount of time had I remembered to look in the logs.

So, those files that you see from time to time that have that .log extension, they really are useful! Don’t forget about them when you’re trying to do, fix, or troubleshoot something. If it weren’t for that file, I would still be trying to figure out how to do what I wanted to do and working on getting that to work with no idea where to look or what to try next.

Ah, the beginning of another month, and time again to do the housekeeping. I have some real-world housekeeping I should do as well, but that seems to be much easier to procrastinate on. I have decided to another section to this post regarding the progress I am making towards my goals for 2009 so be sure to check that out at the end of the post.

Top Commentators

There was a major improvement in the number of comments since last month (almost 3 times as many!) so thank you all. I’m only filling 8 of the 10 spots that I allow in this post this month because there was a 5 way tie for 9th place and I didn’t want to expand the list to 13. My apologies to those who commented and aren’t linked to here, but leave a few more comments this month and make the list next time around.

Dennis Edell - 19 comments
Andrea - 19 comments
Martin - 17 comments
Tammy - 11 comments
Derek - 9 comments
Roman @ FinancialJesus.com - 6 comments
The Blogger Source - 3 comments
Mitch - 3 comments

Thanks you guys for sharing your thoughts on my site here. For those of you who didn’t get the free link this month, you can see how easy it is to get so try for next month!

Advertisers

PerformancingAds hasn’t necessarily been performing for me, but I’ll leave them there for a bit longer yet. The system seems to be working to the point that my site is actually showing some exchange ads and I like the variety in banners that is provided by the system. The one drawback I notice from time to time is that they seem to kill my page’s load time. I haven’t had any complaints yet, so I think I’ll leave it for a while longer to see if I can get anyone to purchase :)

Also, Dennis has decided to start advertising and promoting his personal site and in doing so has acquired a 125×125 in the rotation for those top 4 spots.

Goals For 2009

I’ve had some moderately mixed results in my progress towards my goals for the year. My readership has increased so that’s a positive improvement. Feedburner reports that “on average” I have 33 subscribers and Analytics shows 1,015 visits (which divided by 30 = right around 34 per day) so there has been some improvement since the beginning of the year. This is as much your doing as mine, so thank you all!

I had 22 posts in January which means I’m well on my way to my goal of 250. 22 x 12 = 264 so as long as I keep going at about the same rate I did in January I should be just fine. I know I slowed down a bit towards the end of the month, but I’m trying to budget my time a bit better to be sure and have posts as well as trying to write a post as soon as I get the idea rather than jot the idea down and try to write it later.

In regards to the rest of my goals, I have come up with and began some preliminary work on a new site. I mentioned this previously, but haven’t really done much since then. I was hoping to get a bunch done over the weekend, but that didn’t quite happen…at all. I’ve also done a little bit of research and additional planning (nothing too intense, but more along the lines of keeping track of the little thoughts I have) regarding the additional personal sites I am planning. As far as the income is concerned, I still have a very long way to go before I reach $200 per month, but to be fair, I really haven’t been focusing on that a whole lot yet this year either.

Thanks to all of you for making January an outstanding month and let’s make February even better!

« Previous PageNext Page »

RSS Feed

Supporters