Re: [exim] UCEPROTECT Blacklists and why callouts are abusiv…

Top Page
Delete this message
Reply to this message
Author: Hill Ruyter
Date:  
To: exim users
Subject: Re: [exim] UCEPROTECT Blacklists and why callouts are abusive
Hi

I will just throw in a non-SMTP solution here

If you treat this sudden peak in traffic hitting your servers as a DDOS to
your infrastructure then the best place to stop it is at the ingress to your
network. So you have the firewall do one or more of a number of things

Limit the number of concurrent SMTP sessions fro anywhere to your mail
servers
Limit the number of new SMTP sessions per second
Limit the number of SMTP sessions from a single IP
Limit the amount of bandwidth SMTP can consume on the network

Yes I know that this will be indiscriminate. It will drop a large proportion
of legitimate mail
However as you said many of the spam servers only make a single connection
then go away and you can rest assured that if some legitimate mail was
blocked by the firewall it will be re-sent and arrive in due course if not
immediately upon initial transmission

It seems to me that the problem you described is not about resources used by
the particular purpose of the connection made to your servers but rather
the sheer volume of connections so in fact the reason for your servers
failing was not as much the processing overhead in dealing with the messages
but rather the swamped I/O of the servers/OS


What I suggest from a purely agnostic point of view having read the
arguments is that you guys get together and do a little test
One guy sets up a server and all the others first hit it with bounces and
then hit it with callouts and the results of the resource statistics are
published for comment. Otherwise I see this argument going round in circles
until we all figure out that so much time has passed something not yet
thought of has completely replaced SMTP

Yours
Hill Ruyter

----- Original Message -----
From: "Andrew - Supernews" <andrew@???>
To: "exim users" <exim-users@???>
Sent: Wednesday, October 18, 2006 3:14 PM
Subject: Re: [exim] UCEPROTECT Blacklists and why callouts are abusive


>>>>>> "W" == W B Hacker <wbh@???> writes:
>
> >> That 99.99% peak figure was reached here during a period of a few
> >> hours during which we received more than _10 million_ connection
> >> attempts caused by blowback of all forms, at a domain used only by
> >> a handful of staff which normally gets a few thousand per day.
>
> W> Am I misreading something, or did you just indicate that a
> W> (hopefully rare!) defect in one of your *own* hosting servers
> W> cause *your own* MX the grief?
>
> Where on earth did you get that idea?
>
> The scenario is this:
>
> 1) Some spammer (not anywhere near our network) sends out hundreds of
> millions of spams using random forged addresses at our domain as the
> envelope sender. These are all sent using the usual compromised
> enduser hosts. (I've seen indications that some spammers do this
> routinely, picking a different domain every week or so.)
>
> 2) These spams go to millions of mail servers around the world.
>
> 3) A large fraction of those servers then immediately try and
> connect to _our_ MX in order to do one of three things:
>
> a) send a bounce (everyone agrees this is bad)
> b) send a challenge
> c) do a sender verify callout
>
> All of those things look the same to us. (HELO whatever; MAIL FROM:<>;
> RCPT TO:<randomstuff@ourdomain>)
>
> Result: we end up receiving 300+ SMTP connections per sec, from
> millions of different IPs all of which are actually mailservers.
> Blocking by IP is no help (something like 50% of the traffic last time
> was from IPs that made only _one_ connection during the extent of the
> attack). There is nothing else to block on since the connections are
> not otherwise distinguishable from real traffic.
>
> --
> Andrew, Supernews
> http://www.supernews.com
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
>