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

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Andrew - Supernews
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] UCEPROTECT Blacklists and why callouts are abusive
>>>>> "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