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