On Thu, 29 Jul 2004, Mariano Absatz wrote:
> On Thu, 29 Jul 2004 09:24:31 -0500, Bob Apthorpe
> <[EMAIL PROTECTED]> wrote:
> > On Thu, 29 Jul 2004 10:40:44 -0300 Mariano Absatz <[EMAIL PROTECTED]> wrote:
> >
> > > I was wondering...
> > [...]
> > > What would happen if a spammer intentionally starts putting hundreds
> > > of different invisible random URIs within the message trying to DoS
> > > SURBL?
> >
> > One can compensate for this by testing only a few, visible URIs, or
> > skipping the RHSBL tests altogether and triggering the
> > "MAIL_HAS_CRAPLOAD_OF_INVISIBLE_URIS" rule. Or something like that.
> Right... but I don't want to get rid of SURBL... it is working very
> nicely, it finds a lot of spam and I have yet to find a FP myself
> (though others have seen them)...
>
> My question is more to the people that developed the SURBL plugins for
> SA (or those that have read and understood them), to know if there's
> something in the plugins to avoid a DoS attempt of this kind.
Theoretically possible but not likely. Spammers could create garbage
messages that contained hundreds of random URIs, the first one of those
-would- cause a bunch of lookups on the SURBL servers, but subsequent
instances would just hit your local DNS servers and the cached negative
responses would quickly respond without incurring network overhead.
(this presumes that an intellegent SA admin would know to have a local
caching DNS server ;).
The only way that it could be used as a true DDoS would be if the
spammers were to create unique sets of URLs for -each- message.
This tends to run counter to their bulk sender paradigm as it
would require computational cost and central bandwidth for each
message sent.
If this were to come to pass then we would need that
'MAIL_HAS_CRAPLOAD_OF_INVISIBLE_URIS' rule. ;)
C'est la guerre. B}
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
