Note that this page is for getmail version 4. Debian and some others are still on version 3 (as of October 2004). There are various important differences, so if you're using version 3.x or lower, check out my getmail 3 page.(As of June, 2006, getmail-4.x is available in Debian stable, as getmail4. The default still seems to be getmail-3.x. Note that all development now takes place in getmail-4.x so the Debian using reader might wish to use 4.x rather than 3.x)
In FreeBSD it's in ports, so as root or with root privilege
|cd /usr/ports/mail/getmail; make install clean|
While many distributions now have a package for it, with some, you may have to install it from source. If that's the case, they recommend that you use an included python script. Obviously, you will need python, which is a dependency of getmail.
There is an rpm for getmail in Fedora's stable repo at present. You can follow its progress on RedHat's bugzilla
I'm leaving in what I wrote below when it was in testing, as I figure it's useful for anyone who wants an idea of how to build an rpm.
If you don't want to enable your testing repo, then you can do the following.
This is a page on getmail, not building source rpms, but I'll run through the steps. Make sure you have rpmbuild installed.
rpm -q rpmbuild
If not, install it.
yum -y install rpmbuild
Then, you can grab the spec file from the bugzilla link given above, check to make sure the version is up to date, grab the original tarball from getmail's site and put it in your ~/rpm/SOURCES directory. Then
rpm -ba getmail.spec
to create an rpm. You can then install it with (if the version was 4.7.7.noarch.rpm)
rpm -Uvh ~/rpm/RPMS/noarch/getmail-4.7.7.noarch.rpm
(For a more detailed but still very easy to follow howto on building source rpms, see Falko Timme's page on installing courier-imap on RedHat based systems on howtoforge.com.)
Actually, it's far less work to simply follow the instructions below and just use the tarball, but I use the rpm when I can to be consistant with packages on my system.
Say we were using version 4.2.2
tar xzf getmail-4.2.2.tar.gz cd getmail-4.2.2 python setup.py build python setup.py install
Configuration is fairly simple. In FreeBSD, once it's installed, you'll see that you have a /usr/local/share/examples/getmail/getmailrc-examples file. I just created a $HOME/.getmail directory then copy it over.
mkdir ~/.getmail cp /usr/local/share/examples/getmail/getmailrc-examples ~/.getmail
(The ~ indicates that I'm copying it to my home directory).Like a .fetchmailrc, the permissions should be no higher than 0710.
|chmod 0710 .getmail/getmailrc|
Now, we edit the getmailrc file. Say the user name is john, he's already set up his maildrop, as explained in my mutt article so he wants to use maildrop as his MDA (mail delivery agent). His ISP's pop server is pserver.isp.com, his user name, as stated, is john, and his password is 1234. So, he will open up the getmailrc file and see various examples. We're going to save a few lines and delete most of the others.
(I use maildrop in my examples because it's the program I use. Many others use procmail--if that is the case, one can substitute procmail where I use maildrop.)
In the end, we want something like this
[options] verbose = 0 delete = True [retriever] type = SimplePOP3Retriever server = pserver.isp.com username = john password = 1234 [destination] type = MDA_external path = /usr/local/bin/maildrop unixfrom = True
If one needs to log for troubleshooting or other reasons, put the log in the user's home directory. For example, in the configuration above, one could add
One can now simply type
at a command prompt, and it will fetch mail in a similar manner to fetchmail. One nice thing about it--if one uses fetchmail without also using sendmail, postfix or another heavy duty agent, one receives error messages although mail is retrieved. Using getmail gives no such errors. Although the error messages are harmless, they do annoy some people.
One can also bind the shift+G key in mutt to invoke it. In your .muttrc add
|macro index G"!getmail\n" "Invoke getmail"
macro pager G"!getmail\n" "Invoke getmail"
A few other minor configuration issues from getmail-3.x that might still be necessary in getmail-4 are listed below. I haven't seen them documented on the getmail-4.x docs, but on the other hand, I haven't tried either of them.
If your password has any non alpha-numeric characters--for example, if you used a password like p!#swd you may have to doublequote it in your getmailrc, eg
|password = "p!#swd"|
Also, any option value that contains a percent sign (%) may have
to be escaped with another percent sign. For example, if your user
you would enter it in as
Again, this was the case in 3.x and may or may not be in 4.x.
In general, I like to have getmail running in the background, checking for mail every ten minutes. With fetchmail, one does this with the -d option, making it run as daemon. However, getmail doesn't have this option--while some people write a script to do it, I follow the web page's advice, and run it as cronjob. For the newcomer unfamiliar with cron, it's used to run a job at regular intervals. There are six fields, minutes, hour, day of month, month, day of week and the actual job itself. In this case, I want getmail to run every ten minutes, regardless of the hour, day, etc. Therefore, the only fields specified are minutes and the actual job. This isn't a page about cron, so I'll simply give the procedure to have getmail poll the pop server every ten minutes.
Again, we'll have a user named john. We'll assume that you're new to this (otherwise, you probably wouldn't be reading it) and haven't given john a crontab or any specific jobs. So, as user john
The e means you're going to edit the crontab, You'll probably get an empty editor. In my case, vi is my default editor, so vi opens. For getmail to check for mail every 10 minutes, I would put
|*/10 * * * * /usr/local/bin/getmail|
The first */10 refers to the minutes field, in this case, saying it will be run every 10 minutes. The next 4 asterisks refer to hours, day of month, etc, fields which I am not specifying.
However, in my particular situation, I may want to receive mail on a different computer. So, sometimes I have to stop this cronjob. It's quite easy
This removes the cron job. However, suppose that john wants getmail to check mail overnight, then stop it when he goes to work, then turn it on again when he gets home. Having to rewrite the cronjob could be a nuisance. So he can just save it as a text file
|crontab -l > cron.txt|
The l stands for list. The > redirects the output to a new file called cron.txt. Now, when he gets home, he wants to start the job again. So, once again
Once again, this will open the default editor. He can then simply copy the cron.txt file with whatever method his favorite editor uses. For instance, if he were using vi, and the cron.txt is in his home directory
and the cron job is reinstated.
The above is to illustrate the -r and -l options. The easier way to do this would be to open your crontab with crontab -e and simply comment out the getmail line with a # sign so that it would look like
#*/10 * * * * /usr/local/bin/getmail
One note on this--if you have sendmail or some others running, then cron will email you frequently. Err, very frequently, like each time getmail grabs your mail. So, in that case, you might want to have your crontab read
|*/10 * * * * /usr/local/bin/getmail >/dev/null 2>&1|
(One glitch that I have lately noticed on FreeBSD 5.x is that sometimes the cronjob won't run, or the user will get a message from cron that permission was denied. This is covered on the getmail home page, it has to do with relatively short $PATH of cron. At any rate, the way to fix it is to, as root or with root privilege, use a text editor to open /usr/local/bin/getmail. The first line in FreeBSD is
Change that part to read the full path to python. In FreeBSD it's in /usr/local/bin so you would change that to
One quick note of warning. If you wanted the job to run every two hours and made a crontab like this
* */2 * * *
it would be running every minute. The correct way to specify the job to run every two hours would be
0 */2 * * *
One drawback (for me anyway) with getmail 4.x is that one must now use a seperate getmailrc for each account. If you have homemail and workmail, for example, each one requires their own getmailrc file. We'll call them getmailrc-home and getmailrc-work. Put both in your ~/.getmail directory. Then call it (either from command line or cron) using -r and the rc file's name as shown
getmail -rgetmailrc-home -rgetmailrc-work
I like getmail. As this page hopefully shows, it's not overly difficult to set up for the average home user. Although making a cronjob might seem a nuisance at first, it's quite easy. If you only receive mail on the one computer, you don't have to worry about removing and reinstating it which makes it even easier. Even if you do have to remove and replace it, it only takes a few seconds.
Fetchmail has had various vulnerabilities. Getmail is a nice alternative.