InMotion Hosting Support Ticket — Server Issue Summary vps112473.inmotionhosting.com Date: July 7, 2026 Prepared by: Stack Media Design ======================================================== ISSUE 1: Repeated "exim service down" alerts (every ~15 minutes) ----------------------------------------------------------------- Root Cause: A VPS at IP 157.173.125.17 (hostname: vmi2885286.contaboserver.net, hosted on Contabo) was running a continuous SMTP brute-force authentication attack against accounts on this server. It opened a new SMTP connection every ~9 seconds without releasing prior connections. Over ~15 minutes, these accumulated to the exim maximum of 100 concurrent connections. Once the limit was hit, exim responded to new connections with: "421 Too many concurrent SMTP connections; please try again later." cPanel's service monitor (chkservd) checks exim on port 25 every 15 minutes expecting a "220" banner. When it received the "421" instead, it classified exim as down, forcibly restarted it, and sent the alert email. Exim was never actually crashed — it was being overwhelmed by the attack. Evidence: /usr/local/cpanel/logs/chkservd.log: exim: ** [421 Too many concurrent SMTP connections; please try again later. != 220]: Died ... Restarting exim... /var/log/exim_mainlog: Hundreds of consecutive entries from 157.173.125.17 with connection count climbing 1, 2, 3 ... toward 100. /var/log/exim_mainlog (previous day): dovecot_plain authenticator failed for H=vmi2885286.contaboserver.net (vmi2885286) [157.173.125.17] — cycling through dictionary usernames (ken, kenji, kenneth, kenny, kent, kerl, kernel, etc.) ISSUE 2: Webmail login error (greateratlanticlegal.com/webmail) --------------------------------------------------------------- Symptom: "Unexpected condition from IMAP server, closed or corrupt connection to IMAP. Possible mailbox corruption." Root Cause: Dovecot's authentication worker was backlogged with thousands of pending (and timing-out) auth requests from the brute-force attack connections made before the attacker IP was blocked. Each connection had a 2250-second timeout, so they were all expiring simultaneously and jamming the auth queue. When a legitimate webmail user (Roundcube connecting from 127.0.0.1) attempted to log in, their auth request joined the back of this queue and timed out after 180 seconds, producing the IMAP error. No actual mailbox corruption was present. Evidence: journalctl -u dovecot: auth(albis,157.173.125.17,...): Error: Request 0.1 timed out after 2250 secs auth(reports@greateratlanticlegal.com,...): Error: Request 0.1 timed out after 2100 secs imap-login: Login aborted: Inactivity during authentication: rip=127.0.0.1 ACTIONS TAKEN ------------- 1. Blocked attacker IP 157.173.125.17 in CSF firewall (permanent deny). csf -d 157.173.125.17 2. Added per-host connection limit to exim (/etc/exim.conf): smtp_accept_max_per_host = 10 This ensures no single IP can consume more than 10 of the 100 available connection slots, preventing a recurrence even if a new attacker appears. 3. Enabled SMTP auth brute-force detection in CSF (/etc/csf/csf.conf): LF_SMTPAUTH = 5 (was 0 — disabled) LF_EXIMSYNTAX = 5 (was 0 — disabled) LFD will now automatically block any IP that fails SMTP authentication 5 or more times. 4. Restarted Dovecot to flush the backlogged auth request queue. Webmail login confirmed working immediately after. CURRENT STATUS -------------- - exim: running normally, connection counts staying at 1-5 (normal traffic) - Dovecot: running normally, webmail login confirmed working - 157.173.125.17: permanently blocked in CSF/iptables - LF_SMTPAUTH active: future brute-force IPs will be auto-blocked after 5 failures RECOMMENDATIONS FOR INMOTION ----------------------------- - Review whether LF_SMTPAUTH should be enabled by default on managed VPS plans, as it was disabled (= 0) on this server out of the box. - Consider whether a default smtp_accept_max_per_host value should be set in the base exim configuration to provide baseline protection against connection flooding from a single source.