who else is seeing this new spammer tactic
terry
in looking through the tcpdump captures for my mail servers it is
obvious that the spammers have a new tactic. i have numerous examples,
two examples given below:
example 1:
220 myhost.blauedonau.com ESMTP Sendmail 8.12.8/8.12.8; Tue, 11 Mar
2003 11:26:01 -0600
HELO kcyeafu
MAIL FROM: <Suza...@drotposta.hu>
RCPT TO: <REM...@blauedonau.com>
DATA
From: Narcisa Roundy <Suza...@drotposta.hu>
Subject: <proper name deleted> look and feel great
Date: Wed, 06 Mar 2002 04:00:37 -0800
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
PGh0bWw+DQo8Ym9keQ0KPGJyPg0KSGVsbG8sIHRlcnJ5bHJAYmxhdWVkb25hdS5jb208QlI+
...
czhkbjAsc3otLT5yZTwvYT4NCjwvYT48L2Rpdj48L2JvZHk+PC9odG1sPg0KPC9ib2R5Pg0K
PC9odG1sPg==
.
250 myhost.blauedonau.com Hello NOT-UPDATED-140.de.clara.net
[62.80.28.140] (may be forged), pleased to meet you
250 2.1.0 <Suza...@drotposta.hu>... Sender ok
550 5.7.1 <REM...@blauedonau.com>... Relaying denied. IP name
possibly forged [62.80.28.140]
503 5.0.0 Need RCPT (recipient)
500 5.5.1 Command unrecognized: "From: Narcisa Roundy
<Suza...@drotposta.hu>"
500 5.5.1 Command unrecognized: "Subject: <proper name removed> look
and feel great"
example 2:
220 myhost.blauedonau.com ESMTP Sendmail 8.12.8/8.12.8; Tue, 11 Mar
2003 11:24:23 -0600
HELO sqjnhsx
MAIL FROM: <Conch...@openchile.cl>
RCPT TO: <REM...@blauedonau.com>
DATA
From: Minda Blalock <Conch...@openchile.cl>
Subject: Shape up for summer now <removed>
Date: Wed, 06 Mar 2002 03:59:15 -0800
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
PGh0bWw+DQo8Ym9keQ0KPGJyPg0KSGVsbG8sIHRlcnJ5bHJAYmxhdWVkb25hdS5jb208QlI+
DQo8QlI+DQpBcyBzZTwhLS0zRkFBUlNBaU9TZG5GOXM4ZG4wLHN6LS0+ZW4gb24gTjwhLS0z
RkFBUlNBaU9TZG5GOXM4ZG4wLHN6LS0+QkMsIENCPCEtLTNGQUFSU0FpT1NkbkY5czhkbjAs
c3otLT5TLCBDTjwhLS0zRkFBUlNBaU9TZG5GOXM4ZG4wLHN6LS0+TiwgYW5kIGV2ZW4gT3A8
IS0tM0ZBQVJTQWlPU2RuRjlzOGRuMCxzei0tPnJhaC48YnI+DQpBcyByZXBvcnRlZCBvbiBp
biB0aGUgTjwhLS0zRkFBUlNBaU9TZG5GOXM4ZG4wLHN6LS0+ZXcgRW48IS0tM0ZBQVJTQWlP
U2RuRjlzOGRuMCxzei0tPmdsYTwhLS0zRkFBUlNBaU9TZG5GOXM4ZG4wLHN6LS0+bmQgSm91
PCEtLTNGQUFSU0FpT1NkbkY5czhkbjAsc3otLT5ybmFsIG9mIE1lZGk8IS0tM0ZBQVJTQWlP
U2RuRjlzOGRuMCxzei0tPmNpbmUuPGJyPg0KUmV2ZTwhLS0zRkFBUlNBaU9TZG5GOXM4ZG4w
LHN6LS0+cnNlcyBhZ2luPCEtLTNGQUFSU0FpT1NkbkY5czhkbjAsc3otLT5nIHdoaWxlIGJ1
PCEtLTNGQUFSU0FpT1NkbkY5czhkbjAsc3otLT5ybmluZyBmYTwhLS0zRkFBUlNBaU9TZG5G
OXM4ZG4wLHN6LS0+dCwgd2l0aG91dCBkaWU8IS0tM0ZBQVJTQWlPU2RuRjlzOGRuMCxzei0t
PnRpbmcgb3IgZXg8IS0tM0ZBQVJTQWlPU2RuRjlzOGRuMCxzei0tPmVyYzwhLS0zRkFBUlNB
aU9TZG5GOXM4ZG4wLHN6LS0+aXNlLjxicj4NCkZvcmdldCAgYWdpbmcgYW5kIGRpPCEtLTNG
QUFSU0FpT1NkbkY5czhkbjAsc3otLT5ldGluZyBmb3I8IS0tM0ZBQVJTQWlPU2RuRjlzOGRu
MCxzei0tPmV2ZXIgQW5kIGl0J3MgRzwhLS0zRkFBUlNBaU250
strauss.blauedonau.com Hello [203.195.209.53], pleased to meet you
550 5.7.1 India blocked due to SPAM.
550 5.7.1 India blocked due to SPAM.
550 5.7.1 India blocked due to SPAM.
550 5.7.1 India blocked due to SPAM.
...
bkY5czhkbjAsc3otLT5hbiBtdX421 4.7.0 myhost.blauedonau.com Too many bad
commands; closing connection
NjPCEtLTNGQUFSU0FpT1NkbkY5czhkbjAsc3otLT5sZSBt
YXNzPGJyPg0KYW5kIHJldmU8IS0tM0ZBQVJTQWlPU2RuRjlzOGRuMCxzei0tPnJzaW5nIHRo
ZSByYXY8IS0tM0ZBQVJTQWlPU2RuRjlzOGRuMCxzei0tPmFnZXMgb2YgYWc8IS0tM0ZBQVJT
...
czhkbjAsc3otLT5yZTwvYT4NCjwvYT48L2Rpdj48L2JvZHk+PC9odG1sPg0KPC9ib2R5Pg0K
PC9odG1sPg==
.
MAIL FROM: <Gretch...@ieg.com.br>
the spammers are just 'blasting' the spam at sendmail and do not care
about anyone errors or even smtp commands. i would bet that this is
happening to others and they just do not know it.
so the moral of the story is short of an out right block on tcp
traffic from the spammers' ip addresses they are just going to
find a way to send their spam and it does not really matter if
anyone really receives it.
terry l. ridder ><>
Claus Aßmann
> in looking through the tcpdump captures for my mail servers it is
> obvious that the spammers have a new tactic. i have numerous examples,
> two examples given below:
[example deleted, see original posting]
> the spammers are just 'blasting' the spam at sendmail and do not care
> about anyone errors or even smtp commands. i would bet that this is
> happening to others and they just do not know it.
See sendmail/srvrsmtp.c, look for _FFR_NO_PIPE
and MAXBADCOMMANDS.
The former can delay the spammer (if you fix the code a bit...)
the latter can help you to drop the connection.
terry
> terry wrote:
>
> > in looking through the tcpdump captures for my mail servers it is
> > obvious that the spammers have a new tactic. i have numerous examples,
> > two examples given below:
>
> [example deleted, see original posting]
>
> > the spammers are just 'blasting' the spam at sendmail and do not care
> > about anyone errors or even smtp commands. i would bet that this is
> > happening to others and they just do not know it.
>
> See sendmail/srvrsmtp.c, look for _FFR_NO_PIPE
> and MAXBADCOMMANDS.
i changed MAXBADCOMMANDS from 25 to 2
that drops the connections faster and they are not getting the entire
spam spewed across.
i also defined _FFR_NO_PIPE in site.config.m4
i.e.
define(`confCCOPTS', `-D_FFR_NO_PIPE')
that however does not seem to make a difference.
i am seeing no error messages which from reading the code in theory i
should be seeing.
<being code snippet from sendmail/srvrsmtp.c>
if (bitset(SRV_NO_PIPE, features) &&
sm_io_getinfo(InChannel, SM_IO_IS_READABLE, NULL) > 0)
{
if (++np_log < 3)
sm_syslog(LOG_INFO, NOQID,
"unauthorized PIPELINING, sleeping");
sleep(1);
}
<end code snippet from sendmail/srvrsmtp.c>
>
> The former can delay the spammer (if you fix the code a bit...)
> the latter can help you to drop the connection.
terry l. ridder ><>
Claus Aßmann
> Claus Aßmann wrote in message
> > See sendmail/srvrsmtp.c, look for _FFR_NO_PIPE
> > and MAXBADCOMMANDS.
> i also defined _FFR_NO_PIPE in site.config.m4
> i.e.
> define(`confCCOPTS', `-D_FFR_NO_PIPE')
> that however does not seem to make a difference.
As I wrote:
> > The former can delay the spammer (if you fix the code a bit...)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Did you disable PIPELINING?
if (bitset(SRV_NO_PIPE, features) && ...