Here's one option... http://www.albury.net.au/netstatus/derouted.html As part of our on-going anti-spam policy, we now temporarily de-route (ie, refuse to communicate with) IP addresses who have recently been attempting to send mail to users who do not exist on our service, an excessive number of times within an hour. Experience has shown that these are generally "probes" from spammers, or are actually part of a spamming run. It is our aim to detect these within a second or two, and automatically block the source. In order to minimise collateral damage (ie, refusing mail from legitimate sources), we deliberately do not send back any sort of failure notice (which may lead the other end to bounce or return the mail), instead we simply refuse to talk to the sending site for a period of time. Legitimate sources will queue the mail and try again later, at which time our system will have resumed listening, and will accept the mail. -----Original Message----- From: Andy Bastien [mailto:lists+incidentsat_private] Sent: Thursday, 6 February 2003 7:54 AM To: incidentsat_private Subject: email address probes Where I work, we've getting lots of attempts to send email to random addresses at our domain. All of these attempts have been coming from valid servers operated by AOL, MSN, and Hotmail. I'm guessing that this is an attempt to find some spam targets, although I suppose that there could be something worse in store. I'd like to be able to stop these attempts, but I can't think of a way to do it. All of the attempts are coming from valid servers from some domains that we can't block. They do all have null reverse-paths (MAIL FROM:<>), but I don't think that we can reject on this criteria as null reverse-paths are used to send NDRs and other notifications which we don't want to block. I suppose that we could accept the emails and dump them to /dev/null (or to some tarpit account so that we can inspect them) instead of replying with a "550 User unknown," but I suspect that this could cause us more headaches in the future. Does anyone have any suggestions as to how we could handle this problem? begin 666 InterScan_Disclaimer.txt M5&AE(&EN9F]R;6%T:6]N(&1I<V-L;W-E9"!I;B!T:&ES(&4M;6%I;" H:6YC M;'5D:6YG(&%T=&%C:&UE;G1S*2!M87D@8F4@8V]N9FED96YT:6%L+@T*66]U M('-H;W5L9"!O;FQY(')E860L(&1I<V-L;W-E+"!R92UT<F%N<VUI="P@8V]P M>2P@9&ES=')I8G5T92P@86-T(&EN(')E;&EA;F-E(&]N(&]R#0IC;VUM97)C M:6%L:7-E('1H92!I;F9O<FUA=&EO;B!I9B!Y;W4@87)E(&%U=&AO<FES960@ M=&\@9&\@<V\N($EF('EO=2!A<F4@;F]T('1H92 -"FEN=&5N9&5D(')E8VEP M:65N="!O9B!T:&ES(&5M86EL(&-O;6UU;FEC871I;VXL('!L96%S92!I;6UE M9&EA=&5L>2!N;W1I9GD@;FEN96US;B!B>2!E;6%I;"P-"F]R(')E<&QY(&)Y M(&5M86EL(&1I<F5C="!T;R!T:&4@<V5N9&5R(&%N9"!T:&5N(&1E<W1R;WD@ M86YY(&5L96-T<F]N:6,@;W(@<&%P97(@8V]P>0T*;V8@=&AE(&UE<W-A9V4N M($%N>2!V:65W<R!E>'!R97-S960@:6X@=&AI<R!E+6UA:6P@8V]M;75N:6-A M=&EO;B!A<F4@=&AO<V4@;V8@=&AE#0II;F1I=FED=6%L('-E;F1E<BP@97AC M97!T('=H97)E('1H92!S96YD97(@<W!E8VEF:6-A;&QY('-T871E<R!T:&5M M('1O(&)E('1H90T*=FEE=W,@;V8@;FEN96US;BX@;FEN96US;B!D;V5S(&YO M="!R97!R97-E;G0L('=A<G)A;G0@;W(@9W5A<F%N=&5E('1H870@=&AE( T* M:6YT96=R:71Y(&]F('1H:7,@8V]M;75N:6-A=&EO;B!H87,@8F5E;B!M86EN M=&%I;F5D(&YO<B!T:&%T('1H92!C;VUM=6YI8V%T:6]N(&ES( T*9G)E92!O B9B!E<G)O<G,L('9I<G5S(&]R(&EN=&5R9F5R96YC92X-"@ end ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Feb 06 2003 - 09:17:06 PST