Background
UBE is a common problem. You may decide to drop spammers mail locally or
block them entirely. This prevents you from staying in e-mail contact to
other people, which is unacceptable. You may decide to change your e-mail
address to a crippled form, but remember: This causes other people helping
you a lot of problems and does not prevent spammers from spamming you,
because moste crippling methods are easily uncrippled by scripts.
Teergrubing is a solution to stop spam effectivly. The long term solution
is resevered to legal enforcment. Teergrubing prevents:
- Sending out many e-mails in a short time from a few sites.
- Using of one way dial-in accounts for short term spamming.
- Using misconfigured servers for relaying.
Teergrubing does not block incoming e-mail: You have to delete it anyway. By
the other hand, teergrubing may consume so much ressources at spammer's site,
that he will not longer send you UBE. So every teergrubing host is expected
to be removed from UBE lists after a certain time. In the meantime the
spammer's output of mails per second is dramatically reduced. Misused relays
will run in trouble, so that the responsible admin can not longer ignore
this problem.
For more information please have a look at the
FAQ.
Download it and try it out.
How it works
Startup
The teergrubing wrapper is designed as a drop in replacement of your current
MTA. It works as a daemon and should not be started from the inetd
to avoid ressource shortage at your host. The teergrubing wrapper does not
handle e-mail itself. It will use your own MTA for all kinds of e-mail
delivery.
At first the wrapper starts your MTA as a coprocess. Using this
coprocess the wrapper is able to check all addresses before spawning the
real delivery agent.
If a new SMTP connection is requested, the wrapper checks the requestor's
IP address against his configured table. This table is very similar to a
routing table, so every adress is matched (at least by the default entry).
This lookup results in a delay the current connection is to extend to.
Normaly a SMTP dialog consists of five parts (Welcome,
HELO, MAIL, RCPT, DATA),
so the delayed answer will occur at every part. This may cause a five times
longer delay as configured. Several UBE senders try to shorten the SMTP
dialog by avoiding unnecessary parts. So keep this in mind.
Other UBE senders use the PIPELINING option of ESMTP
defined in RfC 1854. If the requestor's IP address is configured to
delay answers, PIPELINING may cause problems. That's
why it is filtered from the EHLO response for this connection.
Same goes for the experimental protocol CHUNKING.
New connection
Assume a new incoming connection. If the delay is zero, the connection is
hand over directly to a new spawned MTA process.
Holding a connection
If the delay is not zero, every command is send to the MTA coprocess and
the returned answers are send back. The last line is stored instead of send
out. Now, every 10 (configurable) seconds, the a continuation line will be
sent until the (configured) delay is reached. After this, the final line is
sent, so a new command can be send by the other side.
Several MTAs fork on the MAIL FROM: command, so the address
check is made using VRFY. To test the RCPT TO:
parameters, a short dialog containing MAIL, RCPT
and RSET is used. This may cause your MTA to fork, but there
should be an option to prevent this. These steps are done to prevent a
running MTA process for every delayed connection.
In order to prevent relaying, the antispam wrapper maintains two files.
One contains IP areas of customers which are allowed to use this server as
a relay. The other list is used to determine, iff a RCPT TO
address is allowed or not. If not, the wrapper produce an error message
without asking the MTA.
Delivery
After receiving the command DATA, the whole communication
channel will be hand over to a seperate spawned MTA process to deliver. The
whole startup dialog is redone with the MTA to set it up for the DATA
command.
In order to identify the sender, the wrapper inserts an additional
Received line containing the senders IP address and applied delay.
Aftr this line, the original message is passed.
Directly after the message came in, the connection is closed. The wrapper
notices that and cleans up the required resources.
|
zurück