Teergrubing Wrapper

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 ckzurück © 1996-2024 Lutz Donnerhacke @ IKS GmbH Jena Tuesday | 19.Mar.2024