Hello all,
I took [email protected] off the linux-kernel list
for a few days so I can trap the spammers and write their
addresses to `ipchains`. I have been getting approximately
12,000 email messages per day on that system, making it
impossible to use. It's all about the servers spreading
the M$ email virus with the phony message to update to the
latest security patches, plus a few hundred "penis-patch" spam
messages per hour.
Anyway, I am trying to fight back. I have attached a
tar-file which contains the source-code I use to create
anti-spam entries for `ipchains`. It also automatically
ties up the spammers and sends them an email message
asking them to stop, plus it logs the connections.
Cheers,
Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.2.15 on an i586 machine (330.14 BogoMips).
On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> Hello all,
>
> I took [email protected] off the linux-kernel list
> for a few days so I can trap the spammers and write their
> addresses to `ipchains`. I have been getting approximately
> 12,000 email messages per day on that system, making it
> impossible to use. It's all about the servers spreading
> the M$ email virus with the phony message to update to the
the baesyan algorithm learnt about them pretty quickly, so they don't
hurt me anymore (besides some wasted bandwidth).
I doubt answerning those messages will do any good besides generating
more traffic, but I don't know the detail of the virus so I could be
wrong.
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
http://www.cobite.com/cvsps/
svn://svn.kernel.org/linux-2.[46]/trunk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ive been living in a mail hole theese past few years.. Where does one get this
baesyan algorithm ??
Matt H.
On Tuesday 23 September 2003 11:36 am, Andrea Arcangeli wrote:
> On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> > Hello all,
> >
> > I took [email protected] off the linux-kernel list
> > for a few days so I can trap the spammers and write their
> > addresses to `ipchains`. I have been getting approximately
> > 12,000 email messages per day on that system, making it
> > impossible to use. It's all about the servers spreading
> > the M$ email virus with the phony message to update to the
>
> the baesyan algorithm learnt about them pretty quickly, so they don't
> hurt me anymore (besides some wasted bandwidth).
>
> I doubt answerning those messages will do any good besides generating
> more traffic, but I don't know the detail of the virus so I could be
> wrong.
>
> Andrea - If you prefer relying on open source software, check these links:
> rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
> http://www.cobite.com/cvsps/
> svn://svn.kernel.org/linux-2.[46]/trunk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/cJaTleY/n9G/oZ8RAoPjAKCHtX9SsUNSjI+MsXlKwVbxRP5+SwCeIIHB
SdEfk80hkuGGV1tj3bnU5ns=
=+yr7
-----END PGP SIGNATURE-----
Some of us want to get as much spam as possible. Can you figure out why?
On Tue, Sep 23, 2003 at 11:53:04AM -0700, Matt Heler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ive been living in a mail hole theese past few years.. Where does one get this
> baesyan algorithm ??
http://www.spamassassin.org
~/bin/Mail-SpamAssassin-2.60/sa-learn --mbox --spam ~/mail/spam
~/bin/Mail-SpamAssassin-2.60/sa-learn --mbox --spam ~/mail/spam-bad
spam-bad is differentiated because it gets >15 marks, so it gets deleted
immediatly after learning. (see the docs in the package)
but make sure to teach the baesyan about your regular email first, the
number of "ham" must be >= "spam" or your risk losing legitmate email. I
use my inbox as "ham" (that's around 10000 messages).
this is the status of my db
0.000 0 688 0 non-token data: nspam
0.000 0 9722 0 non-token data: nham
see now what it returns for these >100k viruses (Bayesian spam
probability is 99 to 100%)
-------- cut and paste begin ---------
pts rule name description
---- ---------------------- --------------------------------------------------
0.1 HTML_MESSAGE BODY: HTML included in message
1.7 HTML_RELAYING_FRAME BODY: Frame wanted to load outside URL
5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
[score: 1.0000]
0.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.1 HTML_50_60 BODY: Message is 50% to 60% HTML
5.6 IFRAME BODY: IFRAME virus
3.0 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program
0.6 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset
0.1 MIME_SUSPECT_NAME RAW: MIME filename does not match content
1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Encoding: 8bit, Size: 142K --]
Date: Tue, 23 Sep 2003 13:30:38 -0500
From: "microsoft net message system" <[email protected]>
To: "network recipient" <[email protected]>
SUBJECT: Bug Advice
X-Virus-Information: Please visit http://enap.wt.net for more
information
X-Virus-Scanner: Found to be clean
[-- Autoview using lynx -dump '/tmp/mutt.html' --]
IFRAME: [1]cid:mccexrrgkte
Hi.
Undeliverable to [email protected]
[..]
-------- cut and paste end ---------
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
http://www.cobite.com/cvsps/
svn://svn.kernel.org/linux-2.[46]/trunk
Andrea Arcangeli wrote:
> On Tue, Sep 23, 2003 at 11:53:04AM -0700, Matt Heler wrote:
>>
>>Ive been living in a mail hole theese past few years.. Where does one get this
>>baesyan algorithm ??
>
> http://www.spamassassin.org
Another good tactic:
Teegrube is German for tarpit, a trap that wastes
large amounts of spammer resources at little cost
to you.
English FAQ:
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
On Tue, 23 Sep 2003 11:53:04 -0700, Matt Heler wrote:
> Ive been living in a mail hole theese past few years.. Where does one get this
> baesyan algorithm ??
Go to google.com and search "bayesian spam filter". The first two hits
are Paul Graham's articles that started it all. There are at least two
sourceforge.net projects in the first tens hits.
-Paul
On Tue, 23 Sep 2003, Andrea Arcangeli wrote:
> On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> > Hello all,
> >
> > I took [email protected] off the linux-kernel list
> > for a few days so I can trap the spammers and write their
> > addresses to `ipchains`. I have been getting approximately
> > 12,000 email messages per day on that system, making it
> > impossible to use. It's all about the servers spreading
> > the M$ email virus with the phony message to update to the
>
> the baesyan algorithm learnt about them pretty quickly, so they don't
> hurt me anymore (besides some wasted bandwidth).
>
> I doubt answerning those messages will do any good besides generating
> more traffic, but I don't know the detail of the virus so I could be
> wrong.
>
Well it seems that fire-walling the SPAM servers is *not* a good idea.
They are persistant, gang up, and will not give up until they are
able to deliver the mail! When I firewall them, my network traffic
ends up being continuous SYN floods as every spam-server in the
country tries to connect. It doesn't do any good to set `ipchains` to
REJECT instead of DENY. They just keep on banging on the door.
This morning, there was too much traffic on our T3 link to use
a Web crawler, so I had to un-firewall my machine to get about
100,000 (maybe more) mail messages delivered and thrown away.
Procmail is throwing away everything as fast as it can. The
hard-disk LEDs are on continuously, and it takes about 20
seconds to log in. The machine has been eating SPAM mail since
7:00 this morning and it's now 10:15. Maybe, eventually, I
will be able to use my machine again.
To give you a hint of the size of the problem, my /var/log/messages
which logs sendmail activity is about 12 Gb in length. I truncated
it to zero this morning.
Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.2.20 on an i586 machine (330.14 BogoMips).
> They are persistant, gang up, and will not give up until they are
> able to deliver the mail! When I firewall them, my network traffic
> ends up being continuous SYN floods
The ISP who supply this DSL connection have been rejecting connects to
their inbound SMTP server from unlisted IPs for ten minutes after the
initial connection attempt. Retries after ten minutes are accepted,
and future connections are allowed immediately, unless the IP doesn't
make any connections for more than a week.
Apparently, it has reduced the volume of junk mail considerably, as
the 'virus' SMTP engines often don't bother to retry after getting a
4xx error code :-). Obviously it delays genuine traffic coming
through that server slightly.
This may be a good solution to the problem for anyone who has control
of their own SMTP servers.
(Before anybody says that such greylisting by an ISP is irresponsible,
it's not in this case - unlike most DSL providers, they provide a real
static IP address block, (both v4 and v6), and fully configurable and
delegatable reverse DNS. This means that there is no need to use
their SMTP server at all. The most obvious setup is to run your own
primary SMTP server(s), and use theirs as a secondary.)
One theoretical solution to the whole junk mail problem that occurs to
me, would be for everybody to run a spoof open mail relay on port 25
of every IP under their control. By that I mean a script that accepts
mail and claims that it will be delivered, but never delivers it.
Since the IPs running these spoof SMTP servers would never be listed
against an MX record anywhere, no genuine mail would go to them, only
junk.
Anybody sending junk mail via open relays they'd discovered via port
scanning would probably see a >99% reduction in the mails that
actually got through. Presumably the companies who pay for the bulk
mail delivery would learn that their mails were not getting through,
and the business would cease to be profitable.
The only junk mail left would be from identifyable sources which is
_much_ easier to deal with.
Of course IPv6 will bring some of these benefits as hopefully ISPs
will assign static IP allocations, rather than dynamic ones.
John.
if you want to block mail you need to have your MTA return a 500 series
error code when it gets a connection from that IP address, otherwise the
sending MTA will just retry later, resulting in the problem described.
David Lang
On Wed, 24 Sep 2003, John Bradford wrote:
> Date: Wed, 24 Sep 2003 16:08:18 +0100
> From: John Bradford <[email protected]>
> To: [email protected]
> Cc: [email protected], [email protected]
> Subject: Re: Horiffic SPAM
>
> > They are persistant, gang up, and will not give up until they are
> > able to deliver the mail! When I firewall them, my network traffic
> > ends up being continuous SYN floods
>
> The ISP who supply this DSL connection have been rejecting connects to
> their inbound SMTP server from unlisted IPs for ten minutes after the
> initial connection attempt. Retries after ten minutes are accepted,
> and future connections are allowed immediately, unless the IP doesn't
> make any connections for more than a week.
>
> Apparently, it has reduced the volume of junk mail considerably, as
> the 'virus' SMTP engines often don't bother to retry after getting a
> 4xx error code :-). Obviously it delays genuine traffic coming
> through that server slightly.
>
> This may be a good solution to the problem for anyone who has control
> of their own SMTP servers.
>
> (Before anybody says that such greylisting by an ISP is irresponsible,
> it's not in this case - unlike most DSL providers, they provide a real
> static IP address block, (both v4 and v6), and fully configurable and
> delegatable reverse DNS. This means that there is no need to use
> their SMTP server at all. The most obvious setup is to run your own
> primary SMTP server(s), and use theirs as a secondary.)
>
> One theoretical solution to the whole junk mail problem that occurs to
> me, would be for everybody to run a spoof open mail relay on port 25
> of every IP under their control. By that I mean a script that accepts
> mail and claims that it will be delivered, but never delivers it.
> Since the IPs running these spoof SMTP servers would never be listed
> against an MX record anywhere, no genuine mail would go to them, only
> junk.
>
> Anybody sending junk mail via open relays they'd discovered via port
> scanning would probably see a >99% reduction in the mails that
> actually got through. Presumably the companies who pay for the bulk
> mail delivery would learn that their mails were not getting through,
> and the business would cease to be profitable.
>
> The only junk mail left would be from identifyable sources which is
> _much_ easier to deal with.
>
> Of course IPv6 will bring some of these benefits as hopefully ISPs
> will assign static IP allocations, rather than dynamic ones.
>
> John.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
> if you want to block mail you need to have your MTA return a 500 series
> error code when it gets a connection from that IP address, otherwise the
> sending MTA will just retry later, resulting in the problem described.
Adendum: 5xx error code for each RCPT command. Otherwise, some MTAs will
treat 5xx as 4xx.
I've been hit enough with this virus that I've blocked everyone except lkml
and exim lists (by IP) from this server (my backup will accept however and is
on a quicker line)
--
Lab tests show that use of micro$oft causes cancer in lab animals
> if you want to block mail you need to have your MTA return a 500 series
> error code when it gets a connection from that IP address, otherwise the
> sending MTA will just retry later, resulting in the problem described.
Read my post again.
A lot of the simple SMTP engines embedded in viruses _don't_ retry on
4xx error codes. Real SMTP engines do.
That flaw is what we are taking advantage of, to filter out the junk.
I.E. we tell everybody 'come back later'. Genuine mail does, whilst
junk mail often doesn't bother.
John.
correct, but the origional poster attempted to solve the problem at the
network layer, not at the SMTP layer, also while some of the virus engines
will not retry in the face of 400 series errors, if you have a backup MX
configured that accepts it and relays it to you that machine will retry.
my point (and I think part of yours as well) is that you need to block
this at the application layer, not the network layer
David Lang
On Wed, 24 Sep 2003, John
Bradford wrote:
> Date: Wed, 24 Sep 2003 17:45:28 +0100
> From: John Bradford <[email protected]>
> To: [email protected], [email protected]
> Cc: [email protected], [email protected], [email protected]
> Subject: Re: Horiffic SPAM
>
> > if you want to block mail you need to have your MTA return a 500 series
> > error code when it gets a connection from that IP address, otherwise the
> > sending MTA will just retry later, resulting in the problem described.
>
> Read my post again.
>
> A lot of the simple SMTP engines embedded in viruses _don't_ retry on
> 4xx error codes. Real SMTP engines do.
>
> That flaw is what we are taking advantage of, to filter out the junk.
>
> I.E. we tell everybody 'come back later'. Genuine mail does, whilst
> junk mail often doesn't bother.
>
> John.
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
>
> A lot of the simple SMTP engines embedded in viruses _don't_ retry on
> 4xx error codes. Real SMTP engines do.
>
> That flaw is what we are taking advantage of, to filter out the junk.
>
> I.E. we tell everybody 'come back later'. Genuine mail does, whilst
> junk mail often doesn't bother.
This also seems to work with most spammer systems.
But its hard to tell which connections to refuse and
which to accept.
I have had a situation where the connection to the
internet has failed on either the mail server or
its backup relay and amount of spam that day for all users
is greatly reduced.
James