SDB: fetchmail: Collecting Mail from the Provider

fetchmail: Collecting Mail from the Provider

Support knowledgebase (fetchmail)

Question:

How can I collect mail from a POP3 mail server and distribute it on the local mail server?

Solution:

This can be done by means of the program fetchmail (package pop, series n).
(from SuSE Linux 6.3 on: package fetchml, series n; from SuSE Linux 7.1 on: package fetchmail)

The advantage of fetchmail over the older popclient is that the password does not appear in the process table but is only exchanged between the mail server and the POP3 client; the password itself is stored in a separate file.

Installation:

... of course there are many approaches, here just one example:

Let's say the mail server is mail.provider.com. There are two users, asterix and obelix, who are called eve and mary on the host. The passwords (on the mail server) are adam and joseph.

Create a file called /root/.fetchmailrc and enter the following:
```
poll mail.provider.com protocol POP3 user asterix password adam is eve
poll mail.provider.com protocol POP3 user obelix password joseph is mary
```
Since this file contains the passwords, it should only be readable for the user who collects the mail, i.e.:
```
chmod 600 /root/.fetchmailrc
```
The passwords do not necessarily have to be stored in this file. However, in this case the password will be queried each time fetchmail is started.

In our example, an SMTP daemon must be running on the local host or be started by means of inetd whenever necessary, since fetchmail transfers the mail to the local host at port 25.
Another option, which causes procmail to be started directly (i.e. no local SMTP daemon is required) can be effected with the following modification:
```
poll mail.provider.com protocol POP3 user asterix password adam mda "/usr/bin/procmail -d eve"
poll mail.provider.com protocol POP3 user obelix password joseph mda "/usr/bin/procmail -d mary"
```
Now you can collect mail with the command:
```
fetchmail -v --keep -a >> /var/log/fetchmail 2>&1
```
The --keep option makes sure mail is not deleted immediately on the server. We strongly recommend use of this option during the test phase!
Relevant information is logged in /var/log/fetchmail: the -v parameter makes sure only the most important information is recorded.
If the test is successful, we suggest you enter the following command in the crontab or the scripts (ip-up) that establish the network connection:
```
fetchmail -a >> /var/log/fetchmail 2>&1
```
The following crontab entry (crontab -e) regularly retrieves mail once a day at 0200 hours:
```
0 2 * * *  /usr/bin/fetchmail -a >> /var/log/fetchmail 2>&1
```

If you want to fetch mail in fixed time intervals, you can start fetchmail as daemon, e.g. by means of the following init script:
(from SuSE Linux 7.1 on, a suitable script for your version is provided in the file /usr/share/doc/packages/fetchmail/README.SuSE)

#! /bin/sh
# Copyright (c) 1996 SuSE GmbH Nuernberg, Germany.  All rights reserved.
#
# Author: Klaus Franken
#
# /sbin/init.d/fetchmail
#
# please edit /root/.fetchmailrc

. /etc/rc.config
return=$rc_done

case "$1" in
    start)
        echo -n "Starting fetchmail-daemon"
        /usr/bin/fetchmail -d 900 -a -f /root/.fetchmailrc -L /var/log/fetchmail 2>&1 || return=$rc_failed
        echo -e "$return"
        ;;
    stop)
        echo -n "Shutting down fetchmail-daemon"
        /usr/bin/fetchmail -quit || return=$rc_failed
        echo -e "$return"
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
esac

exit 0

For the option -f, you must indicate the path to the .fetchmailrc of the user who wants to collect the mail.
Make this script executable and set the links for the respective runlevels:

cd /sbin/init.d
chmod +x fetchmail
cd /sbin/init.d/rc2.d
ln -s ../fetchmail S06fetchmail
ln -s ../fetchmail K39fetchmail

If you work in runlevel 3 (graphical login), add the following:

cd /sbin/init.d/rc3.d
ln -s ../fetchmail S06fetchmail
ln -s ../fetchmail K39fetchmail

>From SuSE Linux 7.1 on, there is only one thing that still needs to be done:

chmod +x fetchmail
insserv /etc/init.d/fetchmail

In case you use PPP connections, we recommend that the mail is collected automatically every time a connection is established. This can be done e.g. by entering the following in /etc/ppp/ip-up:

#!/bin/sh
# (c) '97, S.u.S.E. GmbH, Fuerth, Germany
# Klaus Franken
# 23.09.97

BASENAME=`basename $0`
INTERFACE=$1
DEVICE=$2
SPEED=$3
LOCALIP=$4
REMOTEIP=$5

case "$BASENAME" in
ip-up)
        /usr/bin/fetchmail -a >> /var/log/fetchmail 2>&1
        ;;
ip-down)
        ;;
*)
        ;;
esac

Multidrop Mode:

Some providers store the mail for various mail users in a single POP3 account. Using the above-mentioned solution, you are able to collect all mail, but the mail would be forwarded to one local user.

Find out whether the provider keeps the target address or rewrites it (usually to the mail account).

If the target address remains unchanged:

In this case, fetchmail can forward the mail directly to the MTA (sendmail, postfix). Make sure the MTA assumes responsibility for the incoming mail.
This is done by means of the options aka or localdomains. aka replaces the domain part with localhost. On the other hand, localdomains keeps the domain part, which means that the MTA must be configured accordingly. If this is not done, the mail is not distributed locally but is resent and comes back to the mailbox :-(. (mail loop!) .fetchmailrc may look somewhat like:

poll mail.provider.com protocol POP3 aka domain1 domain2  user asterix password adam is *

The mail delivery via MTA works us usual; aliases can be defined in /etc/aliases, and a virtusertable (sendmail) is set up (mainly necessary if several users in your system receive mail with the same mail user name, and only the domain part is diferent; in this case at least one of these addresses must be rewritten to another local user).

Example:
The following mail addresses arrive in your mailbox:
name1@prov1.com
name1@prov2.com
Normally, these messages would all be forwarded to the local mailbox name1 (or to a substitute mailbox stated in aliases)
Accordingly, one of the addresses must first be assigned to another user. For this purpose, use the following syntax in the file /etc/mail/virtusertable (sendmail):

name1@prov2.com           localusername

Then execute SuSEconfig.

Limitations:

If you receive mail that does not contain your mail address (e.g. from mailing lists or BCC headers), make sure these are not sent back with an error message ("user unknown"). You can prevent this from happening with the following setting (in .fetchmailrc):

set no bouncemail

However, mail of this kind can not be allocated to individual users, as fetchmail and sendmail can no longer determine to whom the message was originally sent. Therefore, this kind of mail goes to the postmaster.
If you are looking for a secure solution that provides something like a multidrop mailbox, ask your provider for a static IP address and ETRN or mail delivery by UUCP.

However, if you provider inserts an additional header containing the final recipient (e.g. Delivered-To in postfix or qmail, X-Originally-To etc.) you can configure fetchmail in such a way that the respective header is processed.
For this purpose you need the option envelope.
Accordingly, the respective entry in .fetchmailrc may look as follows:

poll mail.provider.com envelope Delivered-To: protocol POP3
   aka domain1 domain2  user asterix password adam is *

If you use qmail, make sure you start fetchmail with the command-line option --qvirtual qmailprefix-.

If the target address is rewritten:

In this case fetchmail has no possibility to identify the recipient. The only possibility is to examine the mail header.

To do this, we suggest that you set up a special user (e.g. mailer) that forwards mail by means of a ~/.procmailrc file.

Examples can be found under http://www.linuxdoc.org/HOWTO/mini/Offline-Mailing.html.

See also:

fetchmail cannot fetch mails

Keywords: FETCHMAIL, POP3, SENDMAIL, MAIL, IMAP

Categories: Email

SDB-fetchmail, Copyright SuSE Linux AG, Nürnberg, Germany - Version: 02. Apr 1997
SuSE Linux AG - Last generated: 02. Aug 2002 by sdb (sdb_gen 1.40.0)