Non Existent User Login Attempts
Log contains several messages from dovecot that are not clear to me exactly what is occurring, single example below. These appear to be login attempts for the same group of non existent user ids from various rip addresses. Am I interpreting these correctly and, if so, is there any issue with just ignoring them?
dovecot: pop3-login: Disconnected: Connection closed (auth failed, 1 attempts in 0 secs): user=<non-existent-user@example.net>, rip=0.0.0.0
Thank you, Bryan
someone is trying to hack the server / account
probably best to block originating ip address?
Thanks - Paul Kudla (Manager SCOM.CA Internet Services Inc.)
Have A Happy Sunday AND Happy Sucessful 2026 !
Scom.ca Internet Services <http://www.scom.ca> 104-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3
Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul@scom.ca
On 2026-01-04 5:29 p.m., Bryan Simmons via dovecot wrote:
Log contains several messages from dovecot that are not clear to me exactly what is occurring, single example below. These appear to be login attempts for the same group of non existent user ids from various rip addresses. Am I interpreting these correctly and, if so, is there any issue with just ignoring them?
dovecot: pop3-login: Disconnected: Connection closed (auth failed, 1 attempts in 0 secs): user=<non-existent-user@example.net>, rip=0.0.0.0
Thank you, Bryan
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
On 04/01/2026 23:29, Bryan Simmons via dovecot wrote:
Log contains several messages from dovecot that are not clear to me exactly what is occurring, single example below. These appear to be login attempts for the same group of non existent user ids from various rip addresses. Am I interpreting these correctly and, if so, is there any issue with just ignoring them?
dovecot: pop3-login: Disconnected: Connection closed (auth failed, 1 attempts in 0 secs): user=<non-existent-user@example.net>, rip=0.0.0.0
Thank you, Bryan
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi Bryan
yes these are authentication failures. In general these are going to be compromised servers/devices where the purpose could be to try to steal login credentials by password guessing, potentially then to use them for smtp authentication to send out spam emails.
To be extremely pragmatic as long as it is for non existent users, they are never going to succeed in logging in whatever password is used. The issue would be if they are also for existent users, since leaving these compromised servers/devices hammering away, they may eventually guess a right password, depending on how strong your password policies are.
Attacks against pop3, imap and managesieve are fewer than against smtp auth, but they do still happen.
Fail2ban may be useful in blocking the ip addresses, though the attackers will just change ip address, and you'll end up with quite a number of ip blocks. But that is preferable to leaving them try over and over again with the risk they will eventually succeed.
Personally I find it helpful to use the Spamhaus XBL and never accept connection attempts from compromised ips. However as others have pointed out, this is not the generally recommended approach. It happens to work for me since I am not expecting users to have ips in XBL and it gets rid of most of the malintentioned connections.
John
Thank you to all for the responses. Since this could eventually become a more serious issue some additional analysis on the log was completed identifying 21 distinct originating IP addresses from the countries listed below. UFW rules were added to block these IP addresses and the authentication failures have stopped.
Korea (the Republic of) [KR] China [CN] United States of America [US] India [IN] Germany [DE] Cameroon [CM] Singapore [SG] Brazil [BR] Russian Federation [RU] Singapore [SG] China [CN]
-Bryan
On Mon, 5 Jan 2026, John Fawcett wrote:
On 04/01/2026 23:29, Bryan Simmons via dovecot wrote:
Log contains several messages from dovecot that are not clear to me exactly what is occurring, single example below. These appear to be login attempts for the same group of non existent user ids from various rip addresses.
dovecot: pop3-login: Disconnected: Connection closed (auth failed, 1 attempts in 0 secs): user=<non-existent-user@example.net>, rip=0.0.0.0
To be extremely pragmatic as long as it is for non existent users, they are never going to succeed in logging in whatever password is used. The issue would be if they are also for existent users, since leaving these compromised servers/devices hammering away, they may eventually guess a right password, depending on how strong your password policies are.
The setting
auth_failure_delay = 5 secs(or longer) may also be useful to slow intense BFDs down. It puts strong passwords further out of reach than they already are. However, not as useful when you're under distributed attack like when 4k+ different IPs slammed us recently for weeks on end.
Personally I find it helpful to use the Spamhaus XBL and never accept connection attempts from compromised ips.
I'll test this out, but I suspect I'll get a few false positives from public WiFi users, etc. These DNSRBLs I currently use catch quite a lot of BFD attackers:
https://www.blocklist.de/en/rbldns.html
https://spamrats.com/rats-auth.phpThere's also many jumbo public networks, mostly Asian, that unless you have users within them, it's better just to blackhole them.
Joseph Tam <jtam.home@gmail.com>
On 06/01/2026 23:27, Joseph Tam via dovecot wrote:
On Mon, 5 Jan 2026, John Fawcett wrote:
On 04/01/2026 23:29, Bryan Simmons via dovecot wrote:
Log contains several messages from dovecot that are not clear to me exactly what is occurring, single example below. These appear to be login attempts for the same group of non existent user ids from various rip addresses.
dovecot: pop3-login: Disconnected: Connection closed (auth failed, 1 attempts in 0 secs): user=<non-existent-user@example.net>, rip=0.0.0.0
To be extremely pragmatic as long as it is for non existent users, they are never going to succeed in logging in whatever password is used. The issue would be if they are also for existent users, since leaving these compromised servers/devices hammering away, they may eventually guess a right password, depending on how strong your password policies are.
The setting
auth_failure_delay = 5 secs
(or longer) may also be useful to slow intense BFDs down. It puts strong passwords further out of reach than they already are. However, not as useful when you're under distributed attack like when 4k+ different IPs slammed us recently for weeks on end.
Personally I find it helpful to use the Spamhaus XBL and never accept connection attempts from compromised ips.
I'll test this out, but I suspect I'll get a few false positives from public WiFi users, etc. These DNSRBLs I currently use catch quite a lot of BFD attackers:
https://www.blocklist.de/en/rbldns.html https://spamrats.com/rats-auth.php
In cases where you can't use these blocklists outright due to risk of your users getting recycled ips which were on the blocklists but are now legitimate, if you block based on having seen an attack behaviour from the ip and then leave the block in place as long as the ip continues to be listed on the blocklist, the probability of blocking legitimate users will be close to zero.
There's also many jumbo public networks, mostly Asian, that unless you have users within them, it's better just to blackhole them.
Joseph Tam <jtam.home@gmail.com>
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
participants (6)
-
bcs＠nanomail.net
-
Bryan Simmons
-
Jason J.G. White
-
John Fawcett
-
Joseph Tam
-
Paul Kudla