On 04/23/2014 02:19 PM, Wietse Venema wrote:
Clogging can be prevented with a global limit on the number of
address verification probes.
I think that should be simulated somehow. However I don't have a 300000+
host zombie spam botnet for me to test with. With four sender hosts
using script like
for i in $(seq 1 100) ; do ( smtp-source -A -N -t
ansu${i}@domain.invalid -s 10 -m 50 -l 1000
some.smtp.server.domain.invalid & ) ; done
I was only able to hit the per domain hard limit of 18.
In theory both sender and recipient verify probes in flight should be
limited by a per receiving host policy like everything else is limited
with default_destination_concurrency_limit to prevent mail queue
congestion. But I think that would be even more of a resource hog than
limiting simply by domain.
Also I think that another possible way to handle this could be using
different queue for verify probes so that handling them doesn't affect
real mail delivery. But which way is most resource friendly?
Obtaining and keeping valid recipient address lists up to date with a few
thousand domains is not an option due to work load issues involved.
The Postfix address verification CACHE, in its default configuration,
will proactively refresh active addresses before they expire.
Therefore, your DDOS should not affect the verification of active
recipients, only those recipients that have expired or that are new.
This should be sufficient to handle a burst of bogus mail.
Verification itself is not the problem, it will be done eventually, but
all legitimate deliveries get delayed for hours when the queue is
congested with verify probes.
A global limit is what I can support on the short term. Your
per-receipient-domain limit is problematic because 1) it leaks
counters when the verify daemon is restarted, and 2) it solves only
the easy half of the problem (recipient domains).
1) Kim's patch is only at proof of concept level not something I would
put directly to postfix source tree as such.
2) I don't see how this would be any different for sender verify probes.
We are facing exactly the same concurrency limits on receiver side there
or even stricter ones.
Mika
