Home

Documentation

Download

FAQ

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.

Sender is in the table from Virtusertable

Recipient is in the table from Virtusertable

Action

Don't care

Yes

PASS

Yes

Don't care

Has user authenticated via POP3?

Yes

No

PASS

FAIL

No

No

FAIL



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:

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:

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

To install SAPD, follow these steps:

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

SourceForge Logo