Developed as a defense against e-mail Spamming, tarpits are services on a computer system (usually a server) that delay incoming connections for as long as possible. The idea is that network abuses such as spamming or broad scanning are less effective if they take too long. The name is analogous with a tar pit, in which animals can get bogged down and slowly sink under the surface.

SMTP Tarpits

Various methods have been discussed and implemented for SMTP tarpits, systems that plug into the MTA (Mail Transfer Agent, i.e. the mail server software) or sit in front of it as a proxy. One method increases transfer time for all mails by a few seconds by delaying the initial greeting message. The idea is that it will not matter if a legitimate mail takes a little longer to deliver, but due to the high volume, it will make a difference for spammers. The downside of this is that mailing lists and other legitimate mass-mailings will have to be explicitly whitelisted or they will suffer, too.

Another method is to delay only known spammers, e.g. by using a blacklist (see Spamming, RBL). OpenBSD has recently integrated this method into their core system, with a special-purpose daemon (spamd) and functionality in the firewall (pf) to redirect known spammers to this tarpit.

Finally, a third method tries to glue tarpits and filtering software together, by filtering e-mail in realtime, while it is being transmitted, and adding delays to the communication in response to the filters "spam likeliness" indicator.
For example, the spam filter would make a "guess" after each line or after every x bytes received as to how likely this message is going to be spam. The more likely this is, the more the MTA will delay the transmission.

IP Level Tarpits

One method of tarpitting, pioneered by a program called "LaBrea", can protect an entire network with a tarpit run from a single machine. The machine listens for ARP requests that go unanswered (indicating unused addresses), then replies to those requests, receives the initial SYN packet of the scanner and sends a SYN/ACK in response. It does not open a socket or prepare a connection, in fact it can forget all about the connection after sending the SYN/ACK.

However, the remote site sends its ACK (which gets ignored) and believes the 3-way-handshake to be complete. Then it starts to send data, which never reaches a destination. The connection will time out after a while, but since the system believes it is dealing with a live, i.e. established connection, it is conservative in timing it out and will instead try to retransmit, back-off, retransmit, etc. for quite a while.

Later versions of LaBrea also added functionality to reply to the incoming data, again using raw IP packets and no sockets or other resources of the tarpit server, with bogus packets that request that the sending site "slow down". This will keep the connection established and waste even more time of the scanner.

See also: Teergrube, Turing tarpit