SMTP after POP HOWTO
====================

Problem:
--------

You have an SMTP and a POP3 Server running on your machine, and your
users shall be able to dial in from somewhere in the outside world and
get and send mail through your mailserver. Simultaneously you want to
protect your mailserver against misuse and spammers, that is, no
unauthorized person shall be able to get mail or use your server as a
relay to send mail.

Fetching mail via the POP3 protocol isn't the problem, since users
have to authenticate themselves with their username and password, but
the SMTP protocol, which is used for sending mail, lacks such a
feature like password authentication. You can only limit the IP
adresses or domains, from which a user is allowed to send mail. This
isn't a solution if your users dial in from different locations or via
providers who assign IP adresses dynamically.

Solution:
---------

A solution to this problem would be to dynamically change the list of
IP adresses, from which users are allowed to relay mail, after the
user has authorized himself via some other means. Since POP3 is often
used in connection with SMTP and has a password authorization
mechanism, it seems to be only logic to combine the two:

A user dials in from somewhere, is dynamically assigned an IP address,
connects to your mailserver via POP3, authenticates himself with his
username and password. The POP3 daemon now adds the IP address to the
list of addresses which are allowed to relay mail. Afterwards your
user may send his outgoing mail via SMTP, which is now possible from
this special IP address.

But what will happen if after our user succesfully fetched and sent
his eMail, and some time later a spammer dials in at the same
provider, obtains the very same address that was assigned to our
honest user an hour ago, and relays tons of spam mail through our
mailserver? A day later the mailbox of the sysadmin will bee flooded
with complaints about the spammer! How to avoid this?

Well, the solution is quite simple: From time to time (every hour or
so) the IP adresses that were inserted into the list of allowed
addresses, and that are older than 15 Minutes or so, have to be
removed again from the list. This gives no 100% guarantee, but chances
are quite good that a spammer will be assigned another address or that
the address has already been removed from the list.


Realisation:
------------

The whole thing was implemented on a SuSE-Linux 6.3 System. We used sendmail
version 8.9.3 and qpopper version 2.53. Besides that, we need the berkley
db library to acces the access.db database file. We used version 1.85 here
since Suse 6.3 uses this rather old version in its sendmail installation.
Maybe you need another version or have it already installed on your system.
All these files can be downloaded in tar.gz format from
http://www.koblenz-net.de/~horn/smtp_after_pop


sendmail
--------

Sendmail is configured to use the acces_db feature, with the following
line in the /etc/mail/linux.mc file:

    FEATURE(`access_db', `hash -o /etc/mail/access.db')

The sendmail configuration file is created from /etc/mail/linux.mc with
the command:

    /usr/bin/m4 /etc/mail/linux.mc > /etc/sendmail.cf

Initially, the access.db file must be created from a text file named
/etc/mail/access with the following command:

    /usr/sbin/makemap hash /etc/mail/access.db < /etc/mail/access

The text file /etc/mail/access may contain lines like the following,
but you may as well start with an empty file.

    192.168.0		RELAY
    spamford.com	REJECT
    ok.spamford.com	OK

which for example means that Clients with addresses 192.168.0.x may
relay mail through this server, while mail from spamford.com is rejected
but mail from ok.spamford.com is accepted.

For further questions about sendmail and its configuration have a glimpse
at the docs...

POP3 daemon
-----------

The POP3 daemon must now be patched so that it inserts the IP-Address of
a client, who has successfully authenticated himself with his POP3
password, is inserted directly into the access.db file. Note that the
address is not inserted into the text file /etc/mail/access, which is
then turned into access.db via makemap, but that the POP3 daemon itself
uses the berkley db library to insert a record directly into the access.db
binary file.

Additionally, the patched POP3 daemon creates an empty file
/etc/mail/popips/<IP>, which is used as a timestamp for later removal of
addresses.

Every hour a cron job is started, which removes all IP-Adresses, that are
older than 15 minutes, from the /etc/mail/popips directory, and also
from the access.db database. The latter is done with a small program,
db.c, that can insert, delete and list records from a db file. Compile it with
"cc db.c -odb -ldb1". Depending on the berkley db version, you may need
to use "-ldb" instead of "-ldb1".

So the address from which the client connected some time ago is no longer valid
for relaying mail via our server! Removal of old adresses is done with the
following short shell script:

#!/bin/sh
#
# cron.hourly: run by cron evera hour.
#

# expire IP addresses from /etc/mail/access.db
DIR="/etc/mail/popips"
if [ -d "$DIR" ]; then
    cd $DIR
    FILES=`/usr/bin/find . -type f -mmin +15 | /bin/sed 's/^.*\///'`
    if [ "$FILES" != "" ]; then
	/bin/rm $FILES
	/root/bin/db /etc/mail/access.db del $FILES
    fi
fi