Re: My first contact with James

[Aaron Knauf]

Kenny,

I don't think that will work, as the traffic hitting JRC's JAMES server is not coming from evt1.net - it is being bounced from (in the example) AOL and from various other spam recipients.

ADK

Kenny Smith wrote:

Hi there,

I would talk to your ISP and see if they can block traffic from evt1.net at
their border routers so that the traffic doesn't even enter the network.

Kenny Smith
JournalScape.com

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


Hmmm.  I see your problem.  If I understand correctly,  your friend has
spewed out his spam via some other server (evt1.net) and spoofed the
reply address to one on your server (which you have closed) - leaving
you fielding the bounces and complaints.

This sort of thing is exactly the reason that blackhole lists such as
RBL exist.  evt1.net is being a bad internet citizen in allowing the
relaying in the first place.

Unfortunately I don't see that there is anything you can do about that,
other than wait it out.

Of course, that doesn't mean that there is no solution.  There are
cleverer people than me on this list.  :-)

ADK


JRC wrote:

I'm not relaying the mail. The spammer spoofed the server at ev1.net and
used a return path to my server. I'm trying to cope with the bounces and
complaints. The bounces are coming from all over the freakin'

place so there

is no single IP address to drop or block.

There's nothing in the logs that I can find that indicates why

James shut

down.
----- Original Message -----
From: "Aaron Knauf" <[EMAIL PROTECTED]>
To: "James Users List" <[EMAIL PROTECTED]>
Sent: Saturday, November 30, 2002 4:09 PM
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]>

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