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