<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 18 May 2018, at 20.19, David Hubbard <<a href="mailto:dhubbard@dino.hostasaurus.com" class="">dhubbard@dino.hostasaurus.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello, given the 2015 revision date, I was curious if anyone can confirm <a href="https://wiki2.dovecot.org/Timeouts" class="">https://wiki2.dovecot.org/Timeouts</a> is still accurate where the 'before login' IMAP timeout remains hard coded?<br class=""><br class="">We're having an issue where blocks of IP's from China and similar locations are crawling IP ranges trying common login credentials, and hanging the connections open in the process. We have clients who have large numbers of employees at single locations, so it isn't possible to reduce the mail_max_userip_connections (assuming it even applies to pre-auth sessions) to a low value. The end result is these connections chew up all the imap-login processes because they sit there until the three-minute timeout is hit, blocking legit users. The only workaround is to raise both the imap and imap-login processes to a massive amount to support all the pre-auth hung open connections.<br class=""><br class="">It would be a lot easier to find a reasonable process limit if we could boot these unauthenticated connections off in a more reasonable amount of time, like 5-10 seconds, but I'm not seeing a way to accomplish that?<br class=""><br class=""></div></div></blockquote><br class=""></div><div><a href="https://github.com/PowerDNS/weakforced" class="">https://github.com/PowerDNS/weakforced</a> is just for situations like this.</div><div><br class=""></div><div>Sami</div></body></html>