SAPD Documentation

Copyleft 2002-2003 Milton Maldonado Junior

How SAPD works

SAPD starts as a daemon that creates 2 listening sockets, one for SMTP and the other for POP3. Since SAPD can't bind the sockets at the ports already used by Sendmail, it allocates two other non-standard ports for this task. The default SAPD ports are 725 for SMTP and 810 for POP3. Once SAPD is running, it relays the two-way traffic from its own ports to the actual Sendmail ports.

• At start, SAPD reads the file /etc/mail/virtusertable, and builds a table with the (hashed) contents from this file. This is done for reasons that will become clear below.

• When a request for POP3 service arrives, SAPD relays the connection to the POP3 server, and also checks if this server grants access to the calling user. If it happens, SAPD stores the IP address and the unix login for this user in a table of trusted users, using a hashed form.

• When a request for SMTP service arrives, SAPD relays the connection to Sendmail, and starts monitoring. Here the table derived from virtusertable is used to decide the course of action, as shown below.

SAPD logs normal events and error events. Normal events are logged to /var/log/messages and error events are logged to /var/log/syslog.

SAPD has a small memory footprint and works multi-threaded, accepting several concurrent connections.

Notes:

If you change items in /etc/mail/virtusertable while SAPD is running, the daemon won't autodetect the changes. To update the table in the daemon's memory, just invoke SAPD again (no need to kill the process already running).

SAPD recognizes an authenticated user for 30 minutos, after this time he needs to make another POP3 authentication (i.e., fetch e-mail) to be allowed to send new e-mails.

TCP port redirection

Without a correct port redirection, SAPD has little use. TCP port redirection is needed for two reasons:

• It's needed to isolate the "real" Sendmail from external world, otherwise no protection can be ensured.
• Most admins will not want to ask the users to change their e-mail client settings to reflect the new ports allocated by SAPD. It's desirable that external clients "see" the standard ports 25 and 110.

Fortunately, IPTABLES allows us to make this redirection with ease. The diagram below shows how the port redirection should work.

Note that the firewalling rules for redirection CANNOT act over the lo (127.0.0.1) interface, as this will cause a circular redirection with disastrous results.

Build and installation

Building SAPD is pretty straightforward:

• Untar the sources: tar zxvf sapd-1.2.tgz
• Go to the SAPD directory: cd sapd-1.2
• Build SAPD: make

You will get an executable file called sapd. Build is finished.

To install SAPD, follow these steps:

• Copy sapd to a system directory, eg /usr/sbin
• Include in the startup script (distro dependent) a line to invoke sapd at boot time
• Include in the firewalling script (distro dependent, too) the lines:
  • /sbin/modprobe iptable_nat
  • iptables -t nat -A PREROUTING -j REDIRECT -i $IFACE_INET -p tcp --dport 25 --to-port 725
  • iptables -t nat -A PREROUTING -j REDIRECT -i $IFACE_INET -p tcp --dport 110 --to-port 810
  • iptables -A INPUT -j ACCEPT -i $IFACE_INET -p tcp --dport 725
  • iptables -A INPUT -j ACCEPT -i $IFACE_INET -p tcp --dport 810

Where $IFACE_INET should be replaced by your server's interface to the Internet.