I would suggest having your firewall block port 25 from that IP address that's causing the DOS. Since it's not a DDOS (distributed denial of service), just blocking a single IP address (or a couple if the guy is using a dial-up) should stop things. Or even if you don't have a network firewall available to configure, just using ipchains/iptables to block traffic from that IP address. If you're using Windows, Zonealarm has a nice free personal firewall you can use to block traffic.

--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/

JRC wrote:
here is one sample of the email i'm receiving by the thousands. any help
would be appreciated......


Return-Path: <>
Received: from omr-d04.mx.aol.com ([205.188.159.7])
          by neonkiwi.com (JAMES SMTP Server 2.1a1-cvs) with SMTP ID 397
          for <[EMAIL PROTECTED]>;
          Sat, 30 Nov 2002 16:13:06 -0600 (CST)
Received: from  rly-xk03.mx.aol.com (rly-xk03.mail.aol.com [172.20.83.40])
by omr-d04.mx.aol.com (v86_r1.15) with ESMTP id RELAYIN1-1130171222; Sat, 30
Nov 2002 17:12:22 -0400
Received: from localhost (localhost)
   by rly-xk03.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
   with internal id RAA26749;
   Sat, 30 Nov 2002 17:12:21 -0500 (EST)
Date: Sat, 30 Nov 2002 17:12:21 -0500 (EST)
From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
 boundary="RAA26749.1038694341/rly-xk03.mx.aol.com"
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

--RAA26749.1038694341/rly-xk03.mx.aol.com

The original message was received at Sat, 30 Nov 2002 17:12:02 -0500 (EST)
from smtpout.ev1.net [207.44.129.133]


*** ATTENTION ***

Your e-mail is being returned to you because there was a problem with its
delivery.  The address which was undeliverable is listed in the section
labeled: "----- The following addresses had permanent fatal errors -----".

The reason your mail is being returned to you is listed in the section
labeled: "----- Transcript of Session Follows -----".

The line beginning with "<<<" describes the specific reason your e-mail
could
not be delivered.  The next line contains a second error message which is a
general translation for other e-mail servers.

Please direct further questions regarding this message to your e-mail
administrator.

--AOL Postmaster



   ----- The following addresses had permanent fatal errors -----
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

   ----- Transcript of session follows -----
... while talking to air-xk04.mail.aol.com.:

RCPT To:<[EMAIL PROTECTED]>

<<< 550 MAILBOX NOT FOUND
550 <[EMAIL PROTECTED]>... User unknown

RCPT To:<[EMAIL PROTECTED]>

<<< 550 MAILBOX NOT FOUND
550 <[EMAIL PROTECTED]>... User unknown

RCPT To:<[EMAIL PROTECTED]>

<<< 550 MAILBOX NOT FOUND
550 <[EMAIL PROTECTED]>... User unknown

RCPT To:<[EMAIL PROTECTED]>

<<< 550 MAILBOX NOT FOUND
550 <[EMAIL PROTECTED]>... User unknown

--RAA26749.1038694341/rly-xk03.mx.aol.com
Content-Type: message/delivery-status

Reporting-MTA: dns; rly-xk03.mx.aol.com
Arrival-Date: Sat, 30 Nov 2002 17:12:02 -0500 (EST)

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 2.0.0
Remote-MTA: DNS; air-xk04.mail.aol.com
Diagnostic-Code: SMTP; 250 OK
Last-Attempt-Date: Sat, 30 Nov 2002 17:12:21 -0500 (EST)

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 2.0.0
Remote-MTA: DNS; air-xk04.mail.aol.com
Diagnostic-Code: SMTP; 250 OK
Last-Attempt-Date: Sat, 30 Nov 2002 17:12:21 -0500 (EST)

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 2.0.0
Remote-MTA: DNS; air-xk04.mail.aol.com
Diagnostic-Code: SMTP; 250 OK
Last-Attempt-Date: Sat, 30 Nov 2002 17:12:21 -0500 (EST)

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 2.0.0
Remote-MTA: DNS; air-xk04.mail.aol.com
Diagnostic-Code: SMTP; 250 OK
Last-Attempt-Date: Sat, 30 Nov 2002 17:12:21 -0500 (EST)

--RAA26749.1038694341/rly-xk03.mx.aol.com
Content-Type: message/rfc822

Received: from  smtpout.ev1.net (smtpout.ev1.net [207.44.129.133]) by
rly-xk03.mx.aol.com (v89.21) with ESMTP id MAILRELAYINXK34-1130171202; Sat,
30 Nov 2002 17:12:02 1900
Received: from neonkiwi.com [207.218.218.79] by smtpout.ev1.net with ESMTP
  (SMTPD32-6.06) id A751DB20070; Sat, 30 Nov 2002 12:45:37 -0600
Message-ID: <[EMAIL PROTECTED]>
X-EM-Version: 5, 0, 0, 21
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
Reply-To: [EMAIL PROTECTED]
X-MSMail-Priority: Normal
To: "Dental Vision Prescription Chiropractic---- Benefits"
<[EMAIL PROTECTED]>
From: "Doug" <[EMAIL PROTECTED]>
Subject: Dental Vision Prescription Chiropractic  All for $11.95 a Month,
80% Coverage
Date: Sat, 30 Nov 2002 12:44:45 -0800
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

NationWide Dental, Vision, Prescription, Chiropractic Care
AmeriPlan USA

NationWide Dental is in every State in the United States, consisting of a =
Networking environment of Dental Providers, Vision Providers, Prescription=
 Providers, Chiropractic Providers=2E
All For Benefits for Only $11=2E95 or $19=2E95 a Month

Do Not Click on Reply:: Click on this------buzzy108@lycos=2Ecom
Save up to 80% on Dental=2E
Save up to 60% on Vision=2E
Save up to 50% on Prescriptions=2E
Save up to 50% on Chiropractic Care=2E
=2E=2E
No waiting Period, go to the Dentist within the next day or so=2E=20
No limits on Visits=2Eor Service=2E
Cosmetic Denistry Included=2E
All Pre Existing Conditions included=2E
Save up to 70% on Orthodontic Treatment!
No Claim Forms=2E
No age Limit,
Membership Fee Guaranteed=2E

Endorsed By the American Dental Association=2E
Endorsed by the E-Commerc
Endorsed by the E-Commerce
Endorsed by the BBB out of Dallas Tx=2E

     =20
To Find your Provider in your Area,  Click on this---E-mail buzzy108@lycos=
=2Ecom  and I will Respond
We have over 36,000 Providers=2E

Single Policy $11=2E95 a Month=20
Every One in House Hold $19=2E95 a Month  up to 20 people=2E
Sign up Large & Small Companies, (Additional Benefits are included)

If you have a Question Click on buzzy108@lycos=2Ecom=2Ecom and put in the =
Subject Respond,=20

To be "REMOVED" , Please type in the Subject Remove, and you will be REMOV=
ED from our system=2E





--RAA26749.1038694341/rly-xk03.mx.aol.com--





----- Original Message -----
From: "Kenny Smith" <[EMAIL PROTECTED]>
To: "James Users List" <[EMAIL PROTECTED]>
Sent: Saturday, November 30, 2002 4:33 PM
Subject: RE: My first contact with James



Hi Aaron,

I don't think this spammer thinks he's sending out spam, I think he
realized

that "JRC" cut off his access and is punishing him.

If all of the traffic is coming from a single IP, he should be able to
black

hole that IP and not worry about it.

Kenny


-----Original Message-----
From: Aaron Knauf [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 30, 2002 2:10 PM
To: James Users List
Subject: Re: My first contact with James


The commonly accepted theory is that spammers will stop sending their
spam when they realise that you are not relaying it.

This is probably not much help to you right now though.  You may need to
configure your router to drop packets from the spammer's address.

Out of interest, do the JAMES logs say why it crashed?  There ought to
be a stack trace somewhere.  My own tests (some months ago) show that
JAMES would start rejecting connections with a socket exception at about
10 new connections/second, but it never actually crashed.

ADK

JRC wrote:

James2.1a1-cvs
JRE 1.4.0_1

I just had an interesting evening with a spammer.

About a week ago I gave a guy an account and noticed he was
testing James to

see if it would relay mail using a different address in the
return path. I

looked at the messages in the spam folder and noticed it was spam he

was

practicing with. I cancelled his account and put his username
in a matcher

that bounces a message saying the account has been cancelled. I
do this for

the first week or two after cancelling an account to take
advantage of the

funny behaviour we have of sending ourselves email.

Anyway, last night this spammer spews countless thousands of
emails using

the same body he was practicing with when he had an account
from me AND he

used that account name in the return path so I got every single
bounce. The

traffic was unbelievable, I had to modify the matcher to just
send to null

to cut down on the traffic. James spontaneously shut down a little

after

midnight. After getting james back up and watching for a while
I decided to

go to bed.

When I got up this morning James was down again, went down at 3:47

this

morning. After restarting James I started getting all of the
bounces that

went to my backup server while James was down.

How do I make it stop? The stuff is still coming?

----- Original Message -----
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Users List" <[EMAIL PROTECTED]>
Sent: Friday, November 29, 2002 4:11 AM
Subject: RE: My first contact with James






-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 29 November 2002 01:24
To: James Users List
Subject: RE: My first contact with James
Aaron.



I agree with all of what you have said.  I have no particular desire

to

change JAMES behaviour here, as it is probably more effort than it is
worth.  (I think that putting mail handling rules in the SMTP dialog
handler instead of the processor would be a bad trade off to
make.  If I am
not mistaken, that would be the only way to achieve it, right?)

Right, this is the dilemma, it would obfuscate James
configuration to have

an additional set of configurable rules here.




The perception of this by non-technical clients is something to be

aware

of, however.  I have struck situations where clients have had the

black

hole thing pointed out to them by those proposing alternate

solutions.  It

does tend to make them uneasy.

I do understand this, but IMO the arguments for both approaches
are equally

compelling, tell them that rejecting mail at the border will allow

their

genuine addresses to be harvested, and that SMTP auth will
reject much of

the mail intended for illicit relaying at the border without
revealing local

usernames.



As for the blackhole behind the firewall scenario - you are absolutely
right.  On thinking about it, I suspect this is actually preferable to
rejection.

IMO blackholes are preferable to rejection on the basis that
they provide no

information whatsoever to the sender, this is one guiding principle of
firewalls, try telnetting to a port protected by a firewall and your
connection just times out, you have no idea whether you were
denied access,

if there was a problem connecting, or even if the machine
really exists on

the network.
By the same token I believe that spam blackholes leave
potential spammers

unable to determine if a real mail service is running, if it is
broken, or

if their mail has been rejected, and it certainly doesn't help them to
determine who the real local users may be.

In my experience spammers will probe SMTP with mail sent to
themselves via

an MTA, if that mail is not recieved (and blackholes, by
definition, don't

deliver it) they will move on and look for other MTA's to probe.

I've seen as many as a dozen such probe attempts in a single day, but

no

more than this and usually only one or two, this doesn't eat up
bandwidth by

even a fraction of that used by unsolicited mail sent to real
users, hence

my rather greater concern for obscuring the genuine mail addresses on

a

domain.
Only once in almost two years have I encountered a spammer who
dumped mail

into James without checking it out first, and this would not
have happened

if the server were demanding SMTP auth.

d.




--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>





--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to