RE: email address probes

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+incidents@yuggoth.net] Sent: Thursday, 6 February 2003 7:54 AM
To: incidents@securityfocus.com
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?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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(&1I2P@9&ES=')I8G5T92P@86-T(&EN(')E;&EA;F-E(&]N(&]R#0IC;VUM97)C
M:6%L:7-E('1H92!I;F9O
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(&1I0T*;V8@=&AE(&UE
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(@http://aris.securityfocus.com
Received on Thu Feb  6 12:17:40 2003