Impact

Our servers experienced a high number of connections from non-Purelymail users, specifically affecting the IMAP protocol. You might have noticed inability to connect to the server, or heavily delayed responses.

Timeline

• 2026/02/28 04:00 UTC: First alarms sent to staff relating to the database connection pool.
• 2026/02/28 14:08 UTC: First identified an attack from distributed IP addresses attempting to log into user accounts via the IMAP protocol.
• 2026/02/28 14:19 UTC: Identified that there were likely 805 IP’s with mass login attempts.
• 2026/02/28 14:23 UTC: User with high flag usage on IMAP restricted. (Unrelated to the incident , but it also contributed to heavy server load).
• 2026/02/28 14:52 UTC: Heavy hitting IP addresses identified from various obfuscation sources.
• 2026/02/28 16:37 UTC: Hotfix completed to create an application level deny list for IP addresses.
• 2026/02/28 17:36 UTC: Hotfix fully deployed and load on server heavily reduced.

Technical Details

AWS has a built-in feature called “Alarms”, that lets its users receive alerts when any server metrics pass a certain threshold. The most common one that we receive are relating to high memory usage on an instance when we hit our peak times for use on the server. It has a whole other series of metrics that get monitored to ensure that if anything were to go wrong, our team gets alerted.

In our code, we utilize a Database Connection Pool. This is a set of connections to the database, to allow for faster and efficient connections to the database to get and edit data. This also helps if any one connection were to go bad, since it can just fetch another connection and utilize that.

So, when we saw our AWS alerts indicating that the vast majority of our database connections were timing out. This can be related to too heavy a load. The concerning thing about this was that we upgraded the database last year when we went into Maintenance Mode. This was to help handle the larger number of connections that we get during peak times. This had always been effective, so the fact that we were getting these alerts indicated a serious load to the database.

Upon checking our server logs, we identified that the vast majority of them were failed login attempts. Every login needs to first hash the provided password, and then compare it against what is stored in the database to see if it is valid.

The number of logs for failed connections indicate that there was plenty of IP’s attempting plenty of users on our service.

We have previously used a Network Access Control List (Network ACL), where we could reject any IP addresses from connecting to our service at all. However, the issue with this is that it is limited to just 20 individual rules, and they were definitely not going to cover the 805 unique IPs that were identified attacking our servers.

Upon learning about the issue, we immediately began implementing a patch to store IPs that will be immediately rejected from using the service, as well as implementing checks at the protocol level to restrict them from accessing our infrastructure.

We have now added automation to oversee our logs and identify any IP addresses heavily hitting our servers for activities like a large number of failed login attempts, or a singular IP attempting and failing to log into multiple users. These IP’s will be restricted when caught.

If you are now receiving any network level errors, like SMTP 421 when trying to connect, then please contact us at support. This can be done via our helpdesk or you can email support@purelymail.com.