Retrieving Emails From Remote Servers With getmail (Debian Etch)

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Thu, 2007-06-14 15:05. :: Debian | Email

Retrieving Emails From Remote Servers With getmail (Debian Etch)

Version 1.1
Author: Falko Timme <ft [at] falkotimme [dot] com>
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 falko@example.com.

 

2 Install getmail

In order to install getmail, all we have to do is run

apt-get install getmail4

as root.

 

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.

vi ~/.getmail/getmailrc

[retriever]
type = SimplePOP3Retriever
server = pop.someprovider.tld
username = falko@someprovider.tld
password = secret

[destination]
type = Maildir
path = ~/Maildir/

The above example assumes that falko has a mail account with the username falko@someprovider.tld 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

getmail

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

crontab -e

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:

vi ~/.getmail/getmailrc

[retriever]
type = SimplePOP3Retriever
server = pop.someprovider.tld
username = falko@someprovider.tld
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.

vi ~/.getmail/getmailrc

[retriever]
type = SimplePOP3Retriever
server = pop.someprovider.tld
username = falko@someprovider.tld
password = secret

[destination]
type = MDA_external
path = /usr/sbin/sendmail
arguments = ("-i", "-bm", "falko@example.com")
unixfrom = true

(As you see, we tell getmail that falko's local email address is falko@example.com.)

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:
.
---

 

3.1 Options

We can also add an [options] section to ~/.getmail/getmailrc where we can change getmail's default behaviour, e.g. like this:

vi ~/.getmail/getmailrc

[...]
[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:

vi ~/.getmail/getmailrc

[...]
[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.


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.