Group-owned mailbox login fails with "UNAVAILABLE" / authserver "aborted" error once group has enough members — regression since 10.0.3?

[koellektiv]

Environment: Cloudron 10.0.3, ~531 users on the instance.

We have several mailboxes owned by groups so that multiple users can access them with their own personal password, as documented in the Email feature. This worked reliably for a long time with a group of 40 members.

Since an automatic update to Cloudron v10 (from v9), logins to this specific group-owned mailbox started intermittently failing — both via SnappyMail and native IMAP clients (Thunderbird, mobile) — while logins to individually-owned mailboxes for the same users continued to work without issue.

Symptom:

SnappyMail shows:

Authentifizierung fehlgeschlagen
Server-Nachricht: UNAVAILABLE Temporary authentication failure.

In docker logs mail, we consistently see this instead of a normal "Authentication failed" for wrong-password attempts on this mailbox:

[INFO] [cloudron] authserver error for <mailbox>@<domain>: The operation was aborted

This looks like an internal timeout in the authserver lookup, not a credentials issue — credentials are confirmed correct and unchanged.

What we've isolated so far:

Changing the mailbox owner to a group with only 2 members: login (including intentional wrong-password test) immediately returns the normal "Authentication failed" — no UNAVAILABLE error.
Testing intermediate group sizes, the threshold where it starts failing appears to be around ~18 members.
Restoring the group back to a larger size reproduces the "aborted"/UNAVAILABLE error again.
This points to the per-login credential check needing to be verified against every group member individually, and this process apparently timing out (or otherwise erroring) once the member count is high enough.
We were previously running with a 40-member owner group for a long time before 10.0.3 without any issues, so this looks like a regression introduced with (or exposed by) the 10.0.3 update rather than a pre-existing hard limit.

Question: Is there a known change in 10.0.3 to the group-mailbox authentication path (timeout value, lookup method, etc.)? Is there a way to configure/increase whatever timeout is causing the "aborted" result, short of reducing group membership below the apparent threshold? We specifically need a shared mailbox usable by ~40 people without requiring each of them to have an individual mailbox (we're aware of the Mailbox Sharing / IMAP ACL feature, but that requires per-user mailboxes, which doesn't fit our use case).

Thank you for some feedback on this issue!

[girish]

I am guessing may be the internal route for auth validation is timing out since it has to check the app password of so many members . Let me check if this is something obvious.

[girish]

@koellektiv I have fixed the issue. Fix will be part of 10.0.5 .

[koellektiv]

Great, thank you very much @girish !