>>>>> "Hill" == Hill Ruyter <hill@???> writes:
Hill> Hi
Hill> I will just throw in a non-SMTP solution here
I'm guessing you've not experienced this yourself.
Hill> If you treat this sudden peak in traffic hitting your servers
Hill> as a DDOS to your infrastructure then the best place to stop it
Hill> is at the ingress to your network. So you have the firewall do
Hill> one or more of a number of things
Hill> Limit the number of concurrent SMTP sessions fro anywhere to
Hill> your mail servers
This is counterproductive; it makes the delays of real mail _worse_
Hill> Limit the number of new SMTP sessions per second
Same here
Hill> Limit the number of SMTP sessions from a single IP
You should probably have been doing this already
Hill> Limit the amount of bandwidth SMTP can consume on the network
Again, counterproductive
Hill> Yes I know that this will be indiscriminate. It will drop a
Hill> large proportion of legitimate mail However as you said many of
Hill> the spam servers only make a single connection then go away and
Hill> you can rest assured that if some legitimate mail was blocked
Hill> by the firewall it will be re-sent and arrive in due course if
Hill> not immediately upon initial transmission
No, the kinds of limits you suggest simply make it close to impossible
for _any_ legit email to get in until after the attack starts to
subside, which isn't the desired response in most cases.
A better approach when under any sort of blowback flood is:
- _increase_ the limit on number of concurrent SMTP sessions
- keep the limit on concurrent sessions per IP small
- disable any pre-greeting or pre-response delays
- avoid doing any DNS lookups at all (especially DNSBLs) until after
you've seen a non-null MAIL FROM
- reject for nonexistent local users early in the RCPT acl
- if you're getting excessive bounces to users that actually exist,
then employ "discard" with appropriate care
Hill> It seems to me that the problem you described is not about
Hill> resources used by the particular purpose of the connection made
Hill> to your servers but rather the sheer volume of connections so
Hill> in fact the reason for your servers failing was not as much the
Hill> processing overhead in dealing with the messages but rather the
Hill> swamped I/O of the servers/OS
Nope, the I/O overhead is nothing; the problem is the sheer number of
connections.
--
Andrew, Supernews
http://www.supernews.com
