+
| |||||||||||||||||||||||||
+
| |||||||||||||||||||||||||
+
| |||||||||||||||||||||||||
+
| |||||||||||||||||||||||||
+
| |||||||||||||||||||||||||
+
|
+
|
cd ~ |
Download the tarball:
wget http://www.tjsi.com/rblsmtpd/rblsmtpd-syslog.tar.gz |
Extract the files from the tarball:
tar -xzf rblsmtpd-syslog.tar.gz |
Change to the directory that was created by the command above:
cd rblsmtpd-syslog |
Read the documentation for anything important that may not have made it to the FAQ yet!
cat rblsmtpd.txt | more |
Run the modified program:
./rblsmtpd |
This should result in the 'usage' line shown below:
usage: rblsmtpd [-b][-R][-t timeout][-r base][-v][-a base] smtpd [arg...] |
Please take careful notice that the [-v] parameter is included in the message. If not, then the reply is most likely being generated by the existing
program which was triggered because it is in your default path. Please verify that the binary is in the current directory and that it has the correct attributes:
ls -l rblsmtpd |
And you should get the following:
-rwxr-xr-x 1 root root 30324 Jun 30 15:12 rblsmtpd |
If the access attributes are not -rwxr-xr-x
then you will need to do the following:
chmod 755 rblsmtpd |
If the user and group are not root root
then you will need to do the following:
chown root:root rblsmtpd |
If you are unable to get the binary to work on your server, you will have to re-compile the source (see below).
We will need to get some information about the current system configuration and make some small adjustments.
First it is necessary to know the location of the current
. If you don't already know where it is, you can use the following command to search your drive:
find / -name rblsmtpd |
The result should show two files, the current one and the modified version. Write down the path for the original. For the sake of this FAQ, the path below will be used (from RedHat 7.2 with PSA 5.05 RPM):
/usr/sbin/rblsmtpd |
Next we will copy the original to a back up and then copy the modified version over the original:
cp /usr/sbin/rblsmtpd /usr/sbin/rblsmtpd.original |
Answer "yes" when it asks you to overwrite the file.
Now we are ready to test it. You will want to send a message from an external account to a mailbox on the server and confirm that your server is properly receiving mail, it can take a couple minutes depending on the servers involved. If after about 15 min you do not receive the message, you may need to re-compile the source to get it to work on your server. So, copy the original back and follow the re-compile instructions below. Just FYI, during the short period that the non-working
was in place any incoming mail will be 'delayed' by the server, and it will be re-delivered later (usually within a couple hours, but could be as soon as a couple minutes). So, there should be no lost mail in the event that
didn't work.
At this point you have successfully installed and tested the modified version of
, but you are still not getting any log entries. This is normal. In order to start the logging you will need to add the
parameter to the command that calls
each time an incoming message is detected. There are several programs that may be calling
although it is probably
(BSD),
(RedHat) or
(part of ucspi-tcp). Due to the many ways even
could be installed, I will use the following as an example. The theory is the same for all installs, but the file and path names will vary.
The last line in the
file reads
which causes
to process all of the files in the
directory. A listing of that directory reveals a file called
so that is the file that needs to be edited in this example. Depending on your setup, your
settings could be in the main
file. We are adding the
right in front of the RBL server parameters, so you are looking for the same file that you used to install/configure the original
program. Basically, your are looking for something like this:
|
The last command (wrapped to three lines) is the call to
and we will insert the
parameter before any
parameters:
|
In the example above I have extended the timeout to 90 seconds (-t
parameter) and also included a few additional RBL servers. Note that this is the correct way to use multiple servers.
When you save the file be sure that there is no line-wrap inserted by your editor (not a problem with vi).
Now, you need to give your daemon a kick to make sure it loads the changes. In my case, I use the following to force
to do a 'soft restart':
/etc/rc.d/init.d/xinetd reload |
Although the following may work for different configurations:
service xinetd reload |
Or using the process id <pid> of the current running daemon:
kill -USR1 <pid> |
Please refer to the documentation for the respective daemons to determine the appropriate command.
Finally, we need to test to see that it is working by sending the following two test messages:
echo "test rblsmtpd" | mail -s "test rblsmtpd" nelson-sbl-test@crynwr.com |
If your root account is setup accordingly, you should get a reply from each of these servers indicating that the message was bounced. But more importantly, you will also be able to confirm the messages got bounced by the log entries. The entries will appear with your other mail entries. In this case it is in the
so after waiting a couple minuted use the following to see the entries:
grep "rblsmtpd:" /var/log/maillog |
This version of rblsmtpd
is based on the ucspi-tcp v0.88 source code. In order to re-compile the source code you will need several files from there. To keep things simple, the following instructions will guide you to download, expand, re-compile the original ucspi-tcp files, and if that works, re-compile the modified rblsmtpd
.
Since the original ucspi-tcp is known valid code, if you have any problems compiling that, you will need to make the required adjustments to your server before you will be able to compile my source code. Configuring your server to be able to compile programs is beyond the scope of this FAQ. However, you may want to start with the following web site to get help on configuring your server to compile the ucspi-tcp programs (which should be enough to compile the modified rblsmtpd
source code):
http://cr.yp.to/ucspi-tcp.html (opens in a new window)
First, we change to our work directory, download the original ucspi-tcp, expand it and change to the directory that was created:
cd ~ |
Then compile the original rblsmtpd.c
files:
make rblsmtpd |
Note: Do not install the ucspi-tcp files (i.e. do not follow the ucspi-tcp instructions to setup or check).
If the files compiled without error swap out the original rblsmtpd.c
with the modified one, and re-compile. This time the compile will be much quicker since it will compile just that one file:
cp rblsmtpd.c rblsmtpd.c.bak |
If that compiled without error you should get something like:
./compile rblsmtpd.c |
Now, in order to proceed with the install steps above, we will replace the binary that was downloaded with the newly compiled program:
rm ~/rblsmtpd-syslog/rblsmtpd |
Proceed to verify that everything worked and install the program starting with Step 2 in the install process above.
Below are the two test entries generated by the test e-mails sent in Step 4 of the install procedure.
Jun 30 15:13:33 ns1 rblsmtpd: relays.ordb.org blocked 193.111.120.47 ordb-test.null.dk - |
This is what each part represents:
Jun 30 15:13:33
: date and time stamp generated by syslog ns1
: local server identification generated by syslog rblsmtpd:
: process name specified by modified rblsmtpd
relays.ordb.org blocked
: RBL server that caused the message to bounce 193.111.120.47
: IP address of the host server attempting to transmit the message ordb-test.null.dk
: host ID of the host attempting to transmit (if available) -
: host info of the host attempting to transmit (if available)In the examples above both hosts include their ID but do not include any info when they connect and attempt to transmit the message. You will find that many SPAM servers do not include either the ID or the info. In the event that the ID or info are not submitted, a single hyphen is inserted to allow for easy reporting (i.e. each entry is a fixed number of columns).
Additional notes on log entries:
The rblsmtpd
program queries the RBL servers in sequence, and the first server in your list to cause the reject is the only one listed in the log. The program does not query the remaining RBL servers if it has already decided to bounce the message. Additionally, since it can take up to 60 seconds (default setting) for each RBL to reply or time-out, having many RBL servers could cause significant delays should one or more of the RBL servers be unavailable. Therefore I strongly suggest that you initially watch your logs to see which of the RBLs you are using tends to reject the most messages, and place that one FIRST in the list of RBLs. That way, the decision to reject the message will most often occur based on the first query, speeding up the mail delivery process.
If relaying is allowed on your server (not advised), all messages received directly from the mail client is also put through the RBL tests (it is just another smtp connection as far as the server is concerned). So, if your clients/users start to complain about excessively long smtp delays, or possibly even time-outs, you may need to remove one or more of the RBL servers.
+ |
+ |
+ |