Aug 20

What is a personal IMAP mail server and why would you want one? Well, such a server is, like it sounds, your very own mail server that you can access via IMAP. You might want such a thing because, like me, you have a lot of different email accounts in different places and you want to collect them all into one central and easy to manage location. I also like having more direct control over my access to my email. For example, if your email account at somewhere.com stops working because their server is down and you need to reference an email stored there, you are out of luck, unless you store your somewhere.com email on your own email server where you can still access it even though their server is inaccessible.

Since I am doing some personal server upgrades and migration, I thought it would be great to share just how to get this kind of server up and running with the most minimal hassle.

For starters, my new mail server is going to be a 32 bit server install of CentOS 5.3. This OS is not at all difficult to install at all and it’s enterprise ready, so it’s plenty reliable.

When you have a machine ready with CentOS running on it, you will need to install Dovecot to handle your IMAP mail access. This is just an yum install away:

yum -y install dovecot

You will need to configure Dovecot after the install. Edit the /etc/dovecot.conf file and make sure the following is set and uncommented:

protocols = imap imaps
mail_location = maildir:~/Maildir

CentOS uses a sendmail/procmail mail combo by default, so in order to make sure your server and IMAP are both using Maildir (so your email gets delivered to you locally) you’ll need to create a file called /etc/procmailrc and in it put:

DEFAULT=$HOME/Maildir/

And then restart your mail service (just to make sure):

service sendmail restart

Once that is set, you will need to turn on Dovecot!

chkconfig dovecot on
service dovecot start

At this point, you should be able to (firewall issues not withstanding) connect to your new mail server via IMAP and see that you have no mail. I am assuming that you have set up mail clients before, the only difference now is you will point to “YourNewMailServerName” and set it up for IMAP mail and use your account name and password from “YourNewMailServerName”.

For example, I created a new server called “Pukwudgie.linc.lan” and created an account on it called linc and made a supersecret password. When I set up my mail client to test the mailserver setup, I set it up to point to Pukwudgie.linc.lan using my username of linc and my password of supersecret via the IMAP protocol. I was able to log directly into my new mail account, which was completely empty.

At some point, you will want to SEND some mail from this account. Since this personal IMAP server is just a place to HOLD your emails, you will need to configure your email client to use your ISP’s smtp address to send through. Follow their instructions for doing this. Most ISP’s do not allow you to use any smtp server other than their own these days.

Now for the fun part. You wan to collect your mail from other places and store it here. This is accomplished through the use of fetchmail. You will need to place a “~/.fetchmailrc” file in your home directory. Please refer to the fetchmailrc man page for full details, but in essence mine looks a lot like this:

poll lincisgreat.org user "linc" there with password "itsasecret"

And you can have as many of those lines in that file as you have email accounts. After creating the rc file, you can run fetchmail to get your mail and have it delivered locally on your new server, where you can access it via IMAP. There are several methods of running fetchmail. You can run it by itself and watch the output as it goes each time, you can run it in daemon mode by starting it with the -d command line switch and specifying a time interval:

fetchmail -d 60

Will check for and grab your email every 60 seconds. Or you could put fetchmail in your crontab and have cron manage getting your mail like so:

*/5 * * * * /usr/bin/fetchmail &> /dev/null

Which would check your email every 5 minutes.

Jun 04

Here’s one for the book…:

I have a script that monitors a process and I want it to email my cellphone (to page me) if things don’t look just right. The problem is that just using “mail” or “mailx” in a script fails because my carrier divines whether or not my return address is real. Obviously a from field that looks like “root@localhost” is just not getting through.

What’s the solution? Enter “mutt”.

Mutt, it seems, will let you specify your from field in the ~/.muttrc file. Also, it works pretty much the same on the command line as mail or mailx. So, I set up mu ~/.muttrc like so:

set realname = "menotyou"
set from = "menotyou@myrealdomain.com"
set hostname = "myrealdomain.com"
set use_from = yes

And then, in the script I send mails like so:

echo "Wow I can send mail!" | /usr/bin/mutt -s "A present for you" myphoneaddr@provider.com

All in one line of course, but BINGO, all the sudden my cell phone springs to life at all hours of the night with information I don’t want to know :-)

Enjoy!

Nov 13

I had this old Belkin wireless router at home, and I knew it was on the way out for some time now. The symptoms were it would occasionally just stop allowing any new connections. A couple weeks ago I purchased a nice little Netgear wireless router to replace it with, but as luck would have it, I didn’t do it fast enough.

I have told stories here about my penchant for procrastination at home. They are all too true I assure you. It’s sort of like that old adage that the mechanic’s car always is in need of repair Likewise, so it is with the System Administrator as well. I went week by week without the gumption to actually configure this new router and dig through the pile of ethernet cables and power wires to replace the old one. I will have to note, however, that I did take a perverse glee from seeing people in my neighborhood connect to my new and powered on but not connected router and try to surf the web. More on that later….

Back to the old router. As you may have guessed, I waited just long enough for it to die while I was not in a position for an immediate fix, throwing my wife and daughter into the thralls of several hours of internet withdrawal. For some reason, at 3:30 in the morning, it dropped it’s connection to my cable modem and steadfastly refused to grab an address from it again. My internal network was working just fine and you could connect to the wireless here, but could not get out through the intertubes whatsoever.

The fix was lengthy, mostly because of poor planning and much haste to get things running again. I put the new router in place fast enough, but, of course, I had to configure it for my specific network needs. This is where the trouble was. I had to change the base addressing to reflect my normal subnet. That was easy. I also had to change the password. That was a snap. I added in my port forwarding information. I turned off the router’s dhcp (I run a dhcp server). I had to fight through several resets of the router and cable modem to get the cable modem to hand out an address to my new router. The real rub came with my dyndns though. You see, in order for me to get into my email, my mail config points to my dyndns address. Well, due to my piss poor planning, all my dyndns account information was (you guessed it) stored in my email. Can’t get into email because no dyndns, can’t set up dyndns because account info in email. Sheesh, what a pain. I spent maybe an hour trying different account names and a dozen old passwords until I found the right combo.

None of that tells you how the uptime was ruined though. That was just an absolutely stupid moment I had. I take great pride normally in pointing out to windows users that you almost never have to reboot a working Linux/unix system. It’s just not necessary unless you can’t get a shell somehow. Well, I must be working too close to the windows guys because before I figured out why I couldn’t get into my email, I spent a good 20 minutes or so troubleshooting and getting increasingly frustrated until, you guessed it, I played the old “lets just reboot the server and see if that fixes things” card. How humbling it was to lose my 195 day uptime and of course the reboot helped nothing. It really was one of those “I could have had a V8″ moments.

So what are some things to be learned form this? Normally I keep a file tucked away that holds all my various logins and account information and passwords. Of course, my dyndns info was missing from this. You can rest assured it’s there now. Although it does not sound like good security practice to do that, there just is no other practical way I can think of to manage all that info than to keep a list somehow. The other thing is, by all means, when you start to get frustrated with a problem, step away for a moment and/or ask someone for advice before you make it worse. I guarantee that if I had stepped away and maybe called Dann or something, I would have realized what a dope was being before I finished dialing the number. Instead I just blundered my way through because I was tired and irritated causing myself even more downtime than was necessary.

Oct 03


I keep forgetting to publish this post, so I had better do it now before I forget again :-)

Many of you know that I dig using (al)pine for reading my email. This is especially true on my Acer Aspire One netbook. I like to have fast access to my email and save space on that tiny flash drive and alpine rolls in around 80someodd k. Anyhow, I also mentioned, I think, that I have several email accounts to keep track of that way, in fact 5 for todays purposes, and I use screen sessions to jump between alpine email sessions on the different accounts.

The trouble with all that is, how do you know when or how many emails you have unread on any of the accounts without jumping through them all, all day long? Well, I decided to go to an old standby for a solution…. Fetchmail.

Fetchmail has the ability to poll your email accounts with a “-c” option which means to just get a count and not download anything. This is just what I need and want!

To start off, you need to configure fetchmail. This is done in your .fetchmailrc file or, in my case, from the command line. I set up all my polling connections in a little script we’ll call “chkmail” like so:

#!/bin/bash
fetchmail -c -u lxxxxx -p imap xxxxxxxxxxxxxxxxx.edu
fetchmail -c -u lxxxxxxxx -p imap xxxxxxxxxxxxxxxxxx.edu
fetchmail -c -u linc -p imap lxxxxxxxxxxxx.org
fetchmail -c -u lxx -p imap lxxxxxxxxxxx.org
fetchmail -c -u linc.fessenden -p imap --ssl imap.gmail.com

Simply put, I call fetchmail, tell it to only count “-c” use the protocol imap “-p” and point it at my imap server’s address. You’ll notice on the gmail entry there is an added “–ssl”. That’s because that imap server uses, you guessed it, ssl authentication. No brainer.

Now the only real stumbling point here is you’ll notice I didn’t pass any passwords. Well, fetchmail doesn’t accept passwords when running from the comand line, it always prompts you for them for security reasons. So, in order to get around that, you’ll need to use a .netrc file, where you can specify your login/password information for the different systems. Your fetchmail program will check your .netrc file before prompting you for a password, so that will make our script runnable without human intervention. My .netrc file looks like so:

machine machinename.org
login linc
password ubersupersecret
machine imap.gmail.com
login linc.fessenden
password ohnoyoudidnt

Now with all that done, you can just run that little chkmail script and get an output of your current mail situation any time you want. Or, if you’re like me, I like to have that info on hand throughout the day, so I call that script in a watch command “watch -n 180 ./chkmail”. This will rerun that chkmail command every 3 minutes and put the output in the current terminal. Works like a champ.

Sep 28

ilohamail

ilohamail


Some times you run into some software that does just what you wanted and no more. ilohamail does just that.

For a long time now I have been running my own mail server of sorts. The short explanation is I use fetchmail to aggregate my email from various sources to my own local home server, which runs imap so that I can get my mail off of it there. It’s a great system with only a couple drawbacks. The first is that I have to use my ISP’s smtp server (they block port 25 to anyone but them). The second is you always have to have access to a mail client, well, until now that is.

Having access to a configurable mail client is not normally a problem, however, there are some times you just want to check your mail somewhere and all you have is a web browser. Tough to do with my setup unless you run some sort of webmail on your home server. Now in the past, that hasn’t been too difficult either, except since I have to push mail through my ISP’s smtp server and don’t run my own, I can’t send mail.

Last night I was browsing around the web and ran into ilohamail (no, it’s not Hawaiian, it’s actually Japanese). Anyway, one of the things that caught my attention about it was you could specify an external smtp server. The other thing was it seemed easy enough to get going, requiring only a webserver and php4 or better.

I actually installed the Ubuntu package, but I can’t imagine installing the source would be any different since it’s all php. Simply enough, you just make the packages ‘source’ directory web enabled. I did that by creating a symlink from my webserver/webmail to that source directory. You can adjust some settings if you wish in the include/local.php file. Other than that, it’s up and running and working! Yay!

Seriously though, I had been looking for something like this for a long time and I have installed several webmail systems to test them out. Nothing has installed as fast and easy as this program. This was literally a 5 minute install and works great!

preload preload preload