On 09/19/17 11:28 -0400, Michael Sofka wrote:
On 09/19/2017 10:12 AM, Dan White wrote:
The botnet is still hammering away, checking those old accounts.
But the bottleneck appears to have been saslauthd threads.
Doubling the thread count from 5 to 10 has resolved the problem
for now. (And,
On 09/19/2017 11:31 AM, Michael Sofka wrote:
On 09/19/2017 10:28 AM, Ken Murchison wrote:
I believe that is it prior to authentication, based on my notes:
https://lists.andrew.cmu.edu/pipermail/info-cyrus/2010-June/033119.html
user_deny.db is NOT checked prior to completion of LOGIN
authen
On 09/19/2017 10:28 AM, Ken Murchison wrote:
I believe that is it prior to authentication, based on my notes:
https://lists.andrew.cmu.edu/pipermail/info-cyrus/2010-June/033119.html
user_deny.db is NOT checked prior to completion of LOGIN authentication,
although it probably could/should. It
On 09/19/2017 10:12 AM, Dan White wrote:
The botnet is still hammering away, checking those old accounts. But
the bottleneck appears to have been saslauthd threads. Doubling the
thread count from 5 to 10 has resolved the problem for now. (And,
If you're comfortable with caching, increase t
On 09/19/2017 10:17 AM, Dan White wrote:
On 09/19/17 10:02 -0400, Michael Sofka wrote:
We have many recalcitrant, bad, accounts constantly checking IMAP,
long after the student has graduated. I would like to use
user_deny.db to simply tell them to go away.
First, would this offer an advanta
On 09/19/17 10:02 -0400, Michael Sofka wrote:
We have many recalcitrant, bad, accounts constantly checking IMAP,
long after the student has graduated. I would like to use
user_deny.db to simply tell them to go away.
First, would this offer an advantage? That is, does "login" check
user_deny
On 09/19/17 09:52 -0400, Michael Sofka wrote:
The botnet is still hammering away, checking those old accounts. But
the bottleneck appears to have been saslauthd threads. Doubling the
thread count from 5 to 10 has resolved the problem for now. (And,
If you're comfortable with caching, incre
We have many recalcitrant, bad, accounts constantly checking IMAP, long
after the student has graduated. I would like to use user_deny.db to
simply tell them to go away.
First, would this offer an advantage? That is, does "login" check
user_deny.db before authenticating, or after?
Second,
Follow up
The botnet is still hammering away, checking those old accounts. But
the bottleneck appears to have been saslauthd threads. Doubling the
thread count from 5 to 10 has resolved the problem for now. (And, might
even explain the occasional slow response from IMAP I've observed.)
