Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

<2000/03/03> Teergrubing FAQ


[ Usenet FAQs | Web FAQs | Documents | RFC Index | Airports ]
Archive-name: net-abuse-faq/teergrube-faq
Last-modified: 2000/03/03
Posting-Frequency: monthly
URL: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
Version: 0.9.1

See reader questions & answers on this topic! - Help others by sharing your knowledge
                           Back Deutsche Version
   
                                Teergrubing FAQ
                                       
   What does a UBE sender really need? What does he sell?
          A certain amount of sent E-Mails per minute. This product is
          called Unsolicited Bulk E-Mail.
          
   How can anyone hit an UBE sender?
          By destroying his working tools.
          
   What?
          E-Mail is sent using SMTP. For this purpose a TCP/IP connection
          to the MX host of the recipient is established. Usually a
          computer is able to hold about 65500 TCP/IP connections from/to
          a certain port. But in most cases it's a lot less due to
          limited resources.
          
          If it is possible to hold a mail connection open (i.e. several
          hours), the productivity of the UBE sending equipment is
          dramatically reduced. SMTP offers continuation lines to hold a
          connection open without running into timeouts.
          
          A teergrube is a modified MTA (mail transport agent) able to do
          this to specified senders.
          
   What are continuation lines?
          Any SMTP host answers to the client command lines with
          specially formatted answer lines. Those lines consist of a
          return code and a human readable comment. If there is a single
          space between the return code and the comment, the server has
          finished its answer. If there is a minus between those parts,
          the client has to wait for further answer lines from the
          server. Here is an example:
          
help
214-This is Sendmail version 8.8.5
214-Topics:
214-    HELO    EHLO    MAIL    RCPT    DATA
214-    RSET    NOOP    QUIT    HELP    VRFY
214-    EXPN    VERB    ETRN    DSN
214-For more info use "HELP <topic>".
214-To report bugs in the implementation send email to
214-    sendmail-bugs@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info

          If such continuation lines are sent very slowly, almost no
          bandwidth is needed and the UBE sending MTA is slowed down
          effectively.
          
   Who developed this idea?
          In <54csin$m6g@white.koehntopp.de> Kristian Köhntopp attributed
          the idea to Axel Zinser. The same article mentions a secondary
          effect: Most MTAs log the whole SMTP dialog, so they have to
          deal with several GB of logs.
          
   What happens if the UBE sender misused other hosts for relaying?
          In this case, the relay host will run into trouble. The
          responsible admin has to stop relaying. So he is urged to
          configure his system correctly...
          
   What happens if the UBE sender recognizes teergrubing hosts in order
          to not spam them any longer?
          Think about it. Mail is still possible, UBE not.
          
   How does a teergrube recognize a spammer?
          Currently, the IP address of the remote host is matched against
          a fixed, configurable table. A standard entry for AGIS (All you
          Get Is Spam = Apex Global Information Systems/Service) is
          derived from the Internic ressources containing 204.137.128/18,
          204.137.192/19, 205.137.48/18, 205.164.64/17, 205.254.160/22,
          205.254.176/21, 207.142/16, 209.14/16.
          
          The IP address of the remote host is immediately available
          after the connection has been established.
          
   How do I determine such IP areas?
          Example for AGIS: 'whois NETBLK-AGIS...'
          
   Will normal MTAs run into trouble, too?
          If a normal MTA is matched by accident nothing special happens.
          The mail transport will take several hours instead of a few
          seconds. On both systems one connection is used. As long as the
          sending host does not spam, it doesn't matter.
          
   How many connections will be tied up by a teergrube on my host?
          A regular teergrube will hold up to ten connections open at a
          time. On the spammer's side there will be up to ten connections
          open for every teergrube he runs into. So decentral resources
          fight against centralised spammer ressources. The more
          teergrubes are installed, the better.
          
   Why can't the spammer buy hundreds of machines to spam? Why can't he
          change to special software without such limitations?
          In this case the spammer has to pay for this development. The
          only question is: Who gives up first: Spammers ordering new
          machines or Admins installing software?
          
          It's very possible that buying new machines results in higher
          spamming costs for the customer.
          
          Teergrubing effectively prevents UBE from one time dial in
          accounts. You can simply call the ISP to tell him: "Your
          customer currently connecting to port ... is currently sending
          UBE. Please cancel his account and sue him."
          
   What happens if the UBE sender targets my MTA to stop me from
          accepting other e-mail?
          All he can do is connect to port 25 until you run out of
          resources. With a non-forking MTA (teergrube) at your site he
          has to invent something new to do this. On the other hand it's
          very unlikely that he will spend time and money in fighting
          against only you.
          
          BTW: If this happens, you are able to sue him for this Denial
          of Service attack.
          
   Isn't it a paradox to slow down internet connections in order to use
          them?
          Yep, but it helps.
          
   This sounds very difficult. I can simply block the spammer, can't I?
          Several hundred teergrubes are able to block spamming worldwide
          without blocking any e-mail. It might be possible that even
          AGIS has customers who send e-mail to your customers for normal
          business. Blocking e-mail is blocking communication. This is
          undesirable.
          
          So blocking helps to protect your users but not other people on
          the net. So blocking does not prevent UBE at all.
          
   How do I start teergrubing?
          If you are the admin of a MX host, install a teergrube. If you
          are only a customer, urge your admin to do this.
          
   Are there any ready to use teergrubes available?
          http://www.de.spam.abuse.net/webland/spam/ especially Axel
          Zinser's patch at ftp://ftp.hiss.han.de/pub/sendmail/. Systems
          unable to receive e-mail can supplied with a special perl
          script from Boston Business Computing.
          
          I developed a general purpose wrapper to use in front of your
          MTA.
          
   How many teergrubes are currently working?
          I don't know. If you do, please feel free to drop me an e-mail.
          
   Does anyone have any experience with teergrubing?
          Axel was able to hold a spammer online for more than two days.
          I have similar records.
          
          In thur.net.admin there is a daily statistics posting from a
          real teergrube.
          
   Does this idea work for Usenet Netnews (NNTP), too?
          No. Usenet News is distributed by flood filling a network of
          neighbours. You would only harm your best friend, not the
          spammer.
          
   How do I express what I do?
          To teergrube. i.e., My host is teergrubing UBE from or via
          AGIS.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
Lutz.Donnerhacke@Jena.Thur.De (Lutz Donnerhacke)





Last Update March 27 2014 @ 02:11 PM