Your question
I’m experiencing something weird with my smartphone (Android with Thunderbird). I could fetch mails and the only thing I changed was (after upgrade 0.15 → 0.16) adding the domain to the username. After some time, I wasn’t able to fetch mails anymore because the IP got blocked. Unblocking it allowed me to fetch mails again befere it got blocked again. So, the login credentials seem to be ok, but the IP gets blocked. Why? I didn’t see that behaviour with my desktop Thunderbird.
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
The most likely cause is that after the 0.15 → 0.16 upgrade, Thunderbird on your phone was retrying the login with the old username format (without the domain) while your phone was also generating authentication failures from the new format, quickly accumulating enough failed attempts to trigger the auto-ban. Stalwart’s built-in auto-ban system counts all authentication failures across all services (IMAP, SMTP, JMAP, ManageSieve) from a given IP into a single counter, with a default threshold of 100 failures per day. Smartphones tend to hammer connections more aggressively than desktop clients when a credential error occurs, which is why you see it on the phone but not the desktop.
Here’s what’s happening and what you can do:
Why the phone gets banned repeatedly:
After you unblock and reconnect, if Thunderbird on your phone still has any stale cached credentials or makes repeated connection attempts that fail (even transiently), those failures quickly pile up again and re-trigger the ban. The threshold might seem generous at 100/day, but mobile email apps can retry very rapidly.
Steps to fix this:
-
Make sure Thunderbird on Android is fully updated to use [email protected] as the username – double-check in its account settings that no old credential is cached anywhere.
-
Raise the authBanRate threshold or set an authBanPeriod (so bans expire automatically instead of being permanent): in the WebUI go to Settings › Security › Settings and adjust authBanRate (e.g. to a higher count or shorter period).
-
Add your phone’s IP (or IP range) to the Allow List to permanently exempt it from auto-banning: in the WebUI go to Settings › Security › Allowed IPs and add an AllowedIp entry for the address. Note that if your phone uses a dynamic IP this may not be practical – but you could add your mobile carrier’s CIDR range if it’s stable enough.
-
Check the reason field on the blocked IP entries in the WebUI (Settings › Security › Blocked IPs) – it will tell you exactly which category triggered the ban (authFailure, loitering, etc.), which helps confirm the root cause.
Relevant docs:
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.
Since both logins (username and username@domain) should work, everything should be fine. But did force quit the app so that there are no stale settings. But the blocking still happens. I never experienced this with 0.15.
And: I’m sure the username & password is correct, since it does work for some time after I removed the ban.
Nevertheless, the reason stated seems to be Exessive failed authorization attempts. They shouldn’t fail, since the credentials are valid.
Just thinking … may it be possible that the problem raised with latest 0.16.6? 
Now the IP is blocked again (log file):
2026-05-20T14:46:47Z INFO Blocked IP address (security.ip-blocked) listenerId = "imaps", localPort = 993, remoteIp = 2a01:599:b01:3dc2:xxxx:xxxx:xxxx:xxxx, remotePort = 47442
But that doesn’t even show up in the admin webinterface.
Any chance the account is used somewhere else? Like a separate calendar or contact integration or something that is still trying to use the username without the domain part?
I use Stalwart only for mails (no calendar etc.). But even then, I think login with the username without domain should still work?
How can I get to the bottom of the problem? @mdecimus ?
Unfortunately, I’m still suffering from this problem.
How can it be that the IP gets blocked using the correct credentials? When I turn on Wi-Fi on the device, the router’s IP address gets blocked. That’s a disaster. 
Doesn’t anyone else have this problem?
Next step is remove the mail account from the smartphone’s Thunderbird app and see what happens …
EDIT: During re-adding the mail account, it didn’t finish because connection refused. But stalwart-cli didn’t show the IP address. After restarting Stalwart, it worked. Let’s see how long …
EDIT2: Blocked again. 
Check the ban decision on logs and what preceded it.
All I see in the log is something like
2026-05-21T12:05:33Z INFO Blocked IP address (security.ip-blocked) listenerId = "imaps", localPort = 993, remoteIp = 2a01:599:b01:5ee2:f420:xxxx:xxxx:xxxx, remotePort = 59606
And Stalwart WebUI/CLI says Excessive failed authentication attempts. That’s strange, since the login credentials are correct.
I’ve increased the limits a bit and am currently waiting to see if and how that affects things.
When an IP address gets banned for the first time, the log correctly shows INFO Banned due…
However, if that same IP address is already banned and attempts to connect again, the log only displays INFO Blocked IP address.
You see INFO Blocked IP address because the IP is still banned.
Below is the log showing how it looks during the first ban:
2026-05-21T12:50:43Z INFO Banned due to authentication errors (security.authentication-ban) listenerId = "submissions", localPort = 465, remoteIp = 192.168.122.1, remotePort = 32840, remoteIp = 192.168.122.1, accountName = "[email protected]"
2026-05-21T12:50:44Z INFO Blocked IP address (security.ip-blocked) listenerId = "submissions", localPort = 465, remoteIp = 192.168.122.1, remotePort = 32844
Anyway, after unbanning you must reload the blocked IPs list.
1 - delete account from device
2 - unban IP
3 - reload blocked IPs list at Management / Action
4 - reconnect device.
Ahhh, thanks lot, that was an important hint. It wasn’t Thunderbird at all. It was Delta Chat. There, the username contains not the primary domain but a different one and thus the login problems.