In message <[EMAIL PROTECTED]>,
Ken Bolingbroke <[EMAIL PROTECTED]> wrote:
>> If you would like to see an example of a very simple multi-connection server
>> that runs as a single process (written in C) as described above, let me know
>.
>
>I'd be very interested in seeing this, if you could post a URL perhaps?
OK. Try this URL:
ftp://ftp.e-scrub.com/pub/teergrube/sendmail-8.9.3-teergrube-patches.gz
Fetch that file and then un-gzip it.
Once you have done that, get a virgin set of Sendmail 8.9.3 sources, unpack
them, cd to the root of the resulting directory, and then use un-gzipped
file as a patchkit to patch the Sendmail sources.
Then read the README.teergrube file which describes everything in great
detail. (The part you are really looking for... the simple milti-connection
daemon... is in the file tgd.c.)
Basically, this patchkit adds a new (but very simple) daemon program to
the Sendmail distribution. After applying the patches, and building
Sendmail as you normally would, you will end up with both an executable
for Sendmail and also an executable called `tgd'... the teergrubing
daemon. (These will both get installed, e.g. into /usr/sbin) when/if
you then install Sendmail as you normally would.)
The code for the tgd daemon, in addition to being a simple demonstration
of a single-process/multi-connection server daemon (as well as a nice
simple demonstration of how to pass open file descriptors via UNIX domain
sockets) also has a great deal of utilitarian value, especially if you
happen to be one of the folks who, like myself, abhor all of the e-mail
spam that seems to ceasely flow through the net's many remaining open
and unsecured mail relays.
Suffice it to say that if we could get a couple of hundred sites running
this daemon, the current unsecured mail server hijacking problem on the
net could be (and most likely would be) almost instantly reduced to per-
haps 1/100th of its current size... not necessarily because all those
remaining open relays would get properly closed/secured by their owners,
but just because they would all suddenly become a lot less effective as
spam conduits.
Please see:
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
for a brief introduction to basic tactical teergrubing. (The tgd daemon
takes this quite a bit further, into what I would call ``advanced hard-core
strategic teergrubing'').
In a nutshell, teergrubing is the name that has been given to a simple
technique that exploits a small but significant known weakness of most
SMTP client implementations. This weakness is exploited to either slow
down or halt the flow of e-mail from some SMTP client to some SMTP server.
Teergrubing has been employed for some time in the fight against e-mail
spam on the net, but I believe that it would be fair to say that the
Sendmail patchkit whose URL is given above, and the `tgd' daemon contained
therein, takes the general strategy of teergrubing to a new level.
Teergrubing has been approved for use throughout the Internet by the
Coalition for Non-Violent Resistance (CNVR).
Ideally, tgd, and the associated Sendmail patches, should be used in
conjunction with some external list of the IP addresses of ``bad'' e-mail
sources that are to be disiplined. In this context, ``bad'' E-mail sources
are either mail servers belonging to known spammers or else unsecured open
mail relays (that may be remotely hijacked by spammers) or both.
Three such lists exist at the present time. They go by the names of ORBS,
RSS, and MAPS RBL. (Most people have probably heard of the MAPS RBL by now.)
The ORBS list is most agressive of the three. It lists essentially any and
all open/unsecured mail relays that have been brought to its attention.
For more info regarding the ORBS list see http://www.orbs.org/.
The RSS list only lists open mail relays that have already been found and
explioted by spammers to relay spam. For more information on the RSS list
see http://www.orbs.org/.
The MAPS RBL list primarily lists IP addresses associated with mail servers
of known spammers, but also lists some open mail relays that have already
been exploited. See http://www.mail-abuse.org/rbl/ for more information on
the MAPS RBL.
The patchkit mentioned above allows any one of these lists to be used to
select which mail senders will be teergrubed. In addition, a locally-
maintained list of ``bad'' e-mail sources may also be specified, in addition
to one of the external lists just mentioned.
One last word about the goals of teergrubing...
It will in fact most likely NEVER be possible to get every last one of the
morons who are still running open/unsecured mail servers to properly secure/
close those servers. Some, perhaps many, will merely upgrade to more recent
version of their current mail server software... versions which include
anti-teergrubing logic... and then just continue on running their servers
as open/unsecured mail relays. That's OK. Those few can then be blocked
individually, and eventually, there will be so few of them remaining that
all the spammers will be fighting over those few remaining open servers,
just like fish struck in an ever-shrinking pond as the dry season approaches.
The real point, for now, is just to force everyone (or almost everyone) to
upgrade to recent-vintage mail servers that at least give them the CHOICE
of whether or not to fully disble relaying by outsiders. (Old mail servers
don't provide such options, but almost all current releases of all popular
mail servers now DO provide this as a configuration choice.)
-- rfg
P.P.S. Real-world experience with tgd indicates that that on the order of
1 out of every 200 mail servers which are teergrubed will result in a nasty
phone call (or e-mail) from the relevant (cluless) system administrator claim-
ing that YOU are spamming HIM, when in fact the exact opposite is what is
actually occuring. In these cases, a calm and patient lesson, provided to
the clueless sysadmin, on how to properly read and interpret the output of
`netstat' almost always succeeds in converting initial hostility to expres-
sions of gratitude.
P.P.S. Experience also indicates that on the order of 1 out of every 1000
or so teergrubed mail servers will result in a nasty phone call (or e-mail)
in which the operator of the mail server on the other end of the open
connection(s) will attempt to assert that what YOU are doing (teergrubing)
is, in some unspecified way, ``illegal''. In such cases, it is best not to
waste time arguing this ridiculous point, but rather to simply assert that
your mail server is indeed accepting mail from the other party's mail
server, but that due to circumstances beyond your control, it is merely
doing so extraordinarily slowly. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
