Zenon Panoussis wrote: > For weeks on end now I am being subjected to what I could call a reverse > spam DDoS attack for lack of better term.
"joe job" is a better term: http://en.wikipedia.org/wiki/Joe_job > Some asshole is sending out > zillions of messages to non-existent users at legitimate domains, using > clearly non-existent sender addresses @myhosteddomain. It seems he is > specifically targetting backup MXs and spam filtering services because > the messages are first accepted for transport, then bounced. Yeah, spammers do that. > The bounces > create a storm of connections to my MX, which in turn causes courier > (0.55.1) to choke and stop receiving mail at all. > ... > So something somewhere gets saturated and simply stops working. This > situation persists forever unless courier is restarted, so the effect > is a full 100% denial of service to legitimate users. Increasing the > number of daemons in authlib/authdaemonrc (tried 5, 10 and 20) doesn't > change courier's behaviour. bofh says 'opt BOFHSUPPRESSBACKSCATTER=none'. > You don't need more authdaemons, just more esmtpd processes. Increase MAXDAEMONS, but not MAXPERC or MAXPERIP. You might also try temporarily using an RBL that lists systems that backscatter: http://en.wikipedia.org/wiki/Backscatter#Backscatter_of_email_spam I've never used one, so I couldn't recommend one in particular, or tell you how likely you are to reject otherwise legitimate mail. It will almost certainly be better than your current situation, though. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
