The best bet in this case is to do exactly as Danny has suggested. Perhaps add to the configuration an ability to recognize and drop any connections identified by a mailet/config directive/database table as an ip/domain that is not allowed. This would function much like a tcp wrappers function. That way it remains completely configurable and does not require active sessions. Danny's position on anti-spam methods is right on. It is better to deny the spammer access to your user list via obscurity than it is to give up that info. By implementing a tcp wrappers type of function, you get the best of both worlds. It's more or less my way of understanding what Danny has already said.
I'll go ahead and implement that if it is a function everyone would like to see. -----Original Message----- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 5:07 AM To: James Developers List Subject: RE: Immediate 550 responses to illegal sends I think comparing the domain with the allowed domains is a good compromise, but remember that internal users will need to send to any domain. I don't see why matchers and even mailets in Handlers has to spoil the abstraction of James. To my mind it enhances it by allowing James to have functionality added by configuration, not coding. I'd go as far as to suggest that handlers ought to have command processors added in the same modular way, so you could add commands by writing a command that used the command API, and add it to one or more handlers through the configuration. d. > -----Original Message----- > From: Anthony Buckton [mailto:[EMAIL PROTECTED]] > Sent: 19 April 2002 07:08 > To: James Developers List > Subject: RE: Immediate 550 responses to illegal sends > > > Hi, > > The prime intent was to get the connection with the spammer closed ASAP > to keep the bills down. He hasn't connected since I implemented 20Hrs > ago and before that I has being hit for 200+ emails every 43mins. In > his last attempt, he send "RCPT"d three times before rudely closing the > socket without so much as a QUIT - result achieved. > > Now, on the filtering, yes I agree that it is very specific and will > only work for some cases and that Serge's wish to enable proper > Matchers would definitely be the way to go even if this means that they > are protocol specific (losing some of the protocol > abstraction/virtualisation that the current James offers) > On email address harvesting, point taken. So as an interim step I'm > planning to change the check to examine ONLY the domains of the > sender/reciever for validity. From there I will leave the user checking > to standard the Matchers process (which is after the email has been > fully rec'd), then the username harvesting would not occur - at least > whilst the spammer is connected to the same SMTP connection. > > But for now, I'm just happy that this smut-monger has decided that I > was too hard and gone on to find someone else! > > Anthony > > At 03:15 PM 18/04/2002 -0700, Craig Skelton wrote... > >I have researched this extensively. Danny is totally correct. MAPS RBL > >and RSS will only list a relay *after* they > >receive relayed mail. (Orbz as well) Therefore there are no concerns. > > > >I have in fact gone out and proven this. I'm going to publish my > >results soon, first to Danny for validation, and then > >on to the group. > > > >Cheers, > >Craig > > > >Ps. Sorry for ever doubting you ;) > > > >-----Original Message----- > >From: Danny Angus [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, April 18, 2002 11:29 AM > >To: James Developers List > >Subject: RE: Immediate 550 responses to illegal sends > > > > > > > > > On checking how other do this, the recommendation what to respond > > > with a "550" message during the SMTP connection to let the sender > > > know that their mail is rejected - > > > >James doesn't do this at the moment, but there are plans to make it do > >it. > >You should also be aware that 550 allows spammers to harvest valid > >addresses > >from your server. > > > >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]>
