RE: My first contact with James

[Kenny Smith <ke...@journalscape.com>]

Hi there,

I would talk to your ISP and see if they can block traffic from evt1.net at
their border routers so that the traffic doesn't even enter the network.

Kenny Smith
JournalScape.com

> -----Original Message-----
> From: Aaron Knauf [mailto:aknauf@xtra.co.nz]
> Sent: Saturday, November 30, 2002 3:38 PM
> To: James Users List
> Subject: Re: My first contact with James
>
>
> 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" <ak...@xtra.co.nz>
> > To: "James Users List" <ja...@jakarta.apache.org>
> > 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" <da...@apache.org>
> >>>To: "James Users List" <ja...@jakarta.apache.org>
> >>>Sent: Friday, November 29, 2002 4:11 AM
> >>>Subject: RE: My first contact with James
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Aaron.Knauf@vodafone.co.nz [mailto:Aaron.Knauf@vodafone.co.nz]
> >>>>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:
> >>
> > <ma...@jakarta.apache.org>
> >
> >>>For additional commands, e-mail:
> >>
> > <ma...@jakarta.apache.org>
> >
> >>>
> >>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail:
> >>
> > <ma...@jakarta.apache.org>
> >
> >>>For additional commands, e-mail:
> >>
> > <ma...@jakarta.apache.org>
> >
> >>>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >
> > <ma...@jakarta.apache.org>
> >
> >>For additional commands, e-mail:
> >
> > <ma...@jakarta.apache.org>
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: My first contact with James

[Aaron Knauf <ak...@xtra.co.nz>]

Kenny,

I don't think that will work, as the traffic hitting JRC's JAMES server 
is not coming from evt1.net - it is being bounced from (in the example) 
AOL and from various other spam recipients.

ADK

Kenny Smith wrote:
> Hi there,
> 
> I would talk to your ISP and see if they can block traffic from evt1.net at
> their border routers so that the traffic doesn't even enter the network.
> 
> Kenny Smith
> JournalScape.com
> 
> 
>>-----Original Message-----
>>From: Aaron Knauf [mailto:aknauf@xtra.co.nz]
>>Sent: Saturday, November 30, 2002 3:38 PM
>>To: James Users List
>>Subject: Re: My first contact with James
>>
>>
>>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" <ak...@xtra.co.nz>
>>>To: "James Users List" <ja...@jakarta.apache.org>
>>>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" <da...@apache.org>
>>>>>To: "James Users List" <ja...@jakarta.apache.org>
>>>>>Sent: Friday, November 29, 2002 4:11 AM
>>>>>Subject: RE: My first contact with James
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Aaron.Knauf@vodafone.co.nz [mailto:Aaron.Knauf@vodafone.co.nz]
>>>>>>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:
>>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>>For additional commands, e-mail:
>>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>>
>>>>>
>>>>>--
>>>>>To unsubscribe, e-mail:
>>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>>For additional commands, e-mail:
>>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>For additional commands, e-mail:
>>>
>>><ma...@jakarta.apache.org>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>
>><ma...@jakarta.apache.org>
>>
>>>For additional commands, e-mail:
>>
>><ma...@jakarta.apache.org>
>>
>>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>