Retrieving Emails From Remote Servers With getmail (Debian Etch)
Author: Falko Timme
Last edited 03/05/2009
Getmail is a program for retrieving emails from remote servers; it is very similar to fetchmail, but more flexible. For example, it can be configured to deliver mails directly to a Maildir or mbox mailbox without the need for an MTA such as Postfix, but of course it can also pipe the mails through an MTA if you want. Getmail can use so called filters such as SpamAssassin and ClamAV to scan the mails, and you can even tell getmail to delete mails on the original server only after a certain number of days.
I do not issue any guarantee that this will work for you!
1 Preliminary Note
I have tested getmail on a Debian Etch system with a local user called falko who has the local email address [email protected].
2 Install getmail
In order to install getmail, all we have to do is run
apt-get install getmail4
3 Configure getmail
Getmail can be configured through per-user configuration files, and getmail can then be run by that very user. To make getmail run automatically, we can create a cron job for that user.
In this chapter I'm assuming that you're logged in as the user falko, not root!
Getmail is looking for the configuration file ~/.getmail/getmailrc, so first we have to create the directory ~/.getmail with permissions of 0700:
mkdir -m 0700 ~/.getmail
Then we create the ~/.getmail/getmailrc configuration file. A getmailrc file must at least have one [retriever] section and one [destination] section.
[retriever] type = SimplePOP3Retriever server = pop.someprovider.tld username = [email protected] password = secret [destination] type = Maildir path = ~/Maildir/
The above example assumes that falko has a mail account with the username [email protected] and the password secret at the server pop.someprovider.tld, and that he has a Maildir account on this server, with ~/Maildir/ being his Maildir directory.
That's already enough to configure getmail. falko could now retrieve emails from the remote server simply by running
Of course, falko doesn't want to start the retrieval manually every few minutes, so we create a cron job for him. Still as the user falko, we run
and create a cron job like this one (which would start getmail every five minutes):
*/5 * * * * /usr/bin/getmail &> /dev/null
Now let's assume falko doesn't have a Maildir account, but an mbox account on this server (/var/mail/falko). All we have to do is modify the [destination] section in ~/.getmail/getmailrc, e.g. like this:
[retriever] type = SimplePOP3Retriever server = pop.someprovider.tld username = [email protected] password = secret [destination] type = Mboxrd path = /var/mail/falko
In the next example we want to pipe the emails that we retrieve from the remote server through an MTA such as Postfix (I assume that Postfix is already installed and working). Postfix can then take care whether it has to deliver the mails to Maildir or mbox, and it can also invoke spam and virus scanners, e.g. through amavisd-new.
[retriever] type = SimplePOP3Retriever server = pop.someprovider.tld username = [email protected] password = secret [destination] type = MDA_external path = /usr/sbin/sendmail arguments = ("-i", "-bm", "[email protected]") unixfrom = true
(As you see, we tell getmail that falko's local email address is [email protected].)
The -i switch in the arguments line is important (thanks to Chris Moules for the hint):
The issue is that some mail, when delivered to sendmail will be truncated. This can happen when the body of the message pulled
from the source contains a line with a single dot (.). In SMTP this is used to indicate the end of the message. When invoking
sendmail on the command line, the default is to end the message on EOF or a single dot.
Quote Postfix sendmail man page:
By default, Postfix sendmail(1) reads a message from standard input until EOF or until it
reads a line with only a . character, and arranges for delivery.
Quote sendmail man page:
With no flags, sendmail reads its standard input up to an end-of-file or
a line consisting only of a single dot and sends a copy of the message
found there to all of the addresses listed.
I had received notices from clients that on occasion, their email was 'corrupt', 'missing' or 'truncated'. After looking at
messages on our server and what was on their mail system it was clear that there was an issue.
A little research showed that the local sendmail needed to be invoked with the '-i' option:
Quote Postfix sendmail man page:
-i When reading a message from standard input, don´t treat a line with only a . character as the end of input.
This makes sendmail wait until the end of the file until the message is submitted.
You can test the -i switch with an email like the following one:
--- Four: .... Three: ... Two: .. One: . ---
We can also add an [options] section to ~/.getmail/getmailrc where we can change getmail's default behaviour, e.g. like this:
[...] [options] verbose = 1 read_all = false delete = true message_log_syslog = true
The above options tell getmail to print messages about retrieved messages, to retrieve only new messages, to delete messages from the remote server after retrieval, and to log to the syslog.
If you'd like to delete only mails older than ten days, you could change the [options] section as follows:
[...] [options] verbose = 1 read_all = false delete_after = 10 message_log_syslog = true
You can learn more about all available options on http://pyropus.ca/software/getmail/configuration.html#conf-options.