james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From abuck...@blackink.net.au (Anthony Buckton)
Subject Re: SMTP RFCs
Date Wed, 07 Aug 2002 22:55:09 GMT
Hi Team,

I implemented James as I connected my machine to the 'net back in 
April. Within hours of my DNS registration, the first "Relay probes" 
started and actually managed to get through. So I set about stopping 
them, well at least so that I no longer stored the emails that sent me. 

Whilst I was able to ghost them, I did still keep getting them (some 
280MB worth of 1K emails) and they still kept being spooled before 
being dropped - simply becuase the first relay worked and there was no 
subsequent "500" message to stop any of the others.
I dropped a note to this list and was given the reason of "email 
address harvesting" for not responding with "500"s but still the emails 
came - now from a much larger group of senders (all of whom were 
spoofed - as discovered by the "NotifySender" mailet).

So I hacked the code - hardwired and all - it check IP's, FROM: and TO: 
and sent "500s" and the problem stopped within 2Hours of me 
implementing. When I went back to main-stream James with a new version, 
the whole nasty cycle started again within 2 days.

Now I have some very neat email applications running thanks to the 
James structure ( HSQL back-end, some custom matchers/mailets ) that 
makes it worthwhile - albeit at a somewhat higher level of touch than I 
had anticipated.
But to make "things right" I am now running a "branched version" of 
James with my own SMTPHandler. I could imagine that if I were an 
administrator trying to use James and had little interest in hacking 
(which is a majority of the world), SendMail or QMail would have been 
installed a long time ago. I have to wonder if this ideal of avoiding 
"email harvesting" will ultimately threaten both the archicture and 
thus suitability of James for non-Java programmers?

BTW: Sacha - I'm interested in the IMAP patches and I like the idea of 
them being available in an "older" version on the CVS.


BlackInk Networks
- Solutions that mean Business.

At 04:41 PM 7/08/2002 +0200, Philipp Taprogge wrote...
>Thomas Jachmann wrote:
>>I know that this
>>behavior is wanted since one main goal is making james as 
>>configurable as
>>possible, so everything was handled within the spool via 
>>But james would still be that configurable if you'd have two 'spools' 
>>matchers/denyers and matchers/mailets.
>What Thomas said about DOS attacks is a good point. Besides even if a 
>james server is not subject to a DOS attack, it still will produce 
>much higher bandwidth costs as it accepts all the spam messages it 
>will later discard. Especially small companies paying for their 
>traffic by the MB will find this an issue.
>Another question that arises is: do we really need this much 
>flexibility at this early point of mail processing? If we merely check 
>the FROM: and TO: fields of the mail or maybe one or two other 
>parameters, wouldn't that be enough to determine whether to accept the 
>message or not?
>You can still have mailets to discard messages based on a much more 
>fine-grained basis, perhaps if a message contains certain phrases and 
>But when a message is denied because of policy ("we do not relay"), 
>the client should be notified immediately.
>One other point that came to my mind...
>I will have a look at the code later, but perhaps one of you could 
>enlighten me in the mean time:
>what exactly happens when james can not process an incoming mail 
>because of an internal error?
>Is there a mechanism to send the client a 550 response or will james 
>accept the message with a 200 and then fail to process it?
>         Philipp
>To unsubscribe, 
>e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message