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