Kim B. Heino:
> Hello,
>
> I'm one of the maintainers of multi-node spam checking service. We were
> recently hit by DDoS attack. We received hundreds of emails per second,
> all targeted to randomst...@single.client.com. Unfortunately client.com
> had "unknown receiver tarpit" feature enabled and we had (must have)
> "reject_unverified_recipient" option enabled on our side. This resulted
> hundreds of verify probes per second, but client replied to less that
> one per second. This resulted HUGE mail queue of verify probes plus
> couple of real emails. Basically we and all of our clients were DDoS'ed
> as our Postfix installation was using 99% of time to handle those
> queued verify probes.
>
> There are lot of different concurrency limits in Postfix but none for
> verify. I quickly came up with attached patch which solved this DDoS
Address verification probes are subject to concurrency and rate
limits just like regular mail.
However, you are looking for a solution BEFORE the mail queue,
that stops the verify daemon from sending probes.
> attack. It's not complete and it's quite dirty, but I'm sending it here
> for comments before I clean it up.
>
> Basic idea in patch:
>
> Chunk #1: Function to increase/decrease/get current concurrency value
> per receiver domain. I'm re-using verify_map for this value, stored as
> key = "@@domain.com", value = "0". I know that value "0" will be purged
> by verify_cache_validator() but that's not a problem.
Instead of per-domain quota, would not it be sufficient to impose
a global limit on the total number of pending verify requests for
information that is not already cached? Then use something like
"random drop" to keep the number within bounds.
Wietse
