Re: My first contact with James

[Aaron Knauf]

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]>