Mailu: Maximum number of connections from user+IP exceeded

[IT-MBiT]

Hi, we have a problem... :-)
We have changed the original value of "AUTH_RATELIMIT" to "AUTH_RATELIMIT=100/minute;6000/hour", but logs continue to say " Maximum number of connections from user+IP exceeded (mail_max_userip_connections=20)" while reading response from upstream..."
We have made docker-compose dow and docker-compose up -d, but without result.
How can we change the default limit set during the installation?
Thanks in advance.

[kaiyou]

That is not related to the ratelimit but to a dovecot limit that allows so many connections per user and originating ip.

Either you indeed have that many clients connected to your server something is wrong and dovecot has open connections hanging

[hoellen]

You can override this value by creating a file
/mailu/overrides/dovecot.conf

with the following content:

protocol imap {
  mail_max_userip_connections = 100
}

[IT-MBiT]

Hi! Thank you very much for your replay... Overriding the value worked very well.
We have another two questions... And we don't know if we can ask here or if we need to open another thread.
We have a problem with a request to sended mail (request a read receipt and request a delivery receipt).
In one account when recipient attempt to send a read request gets this error message: "Recipient address rejected: User unknown in virtual mailbox table"
The delivery request don't say nothing, but the request don't return.
Another account don't have a read error and request a read receipt it works, but a request to delivery don't works and don't say nothing.
How we can resolve this problem?

[Nebukadneza]

Hi There,

The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.

To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.

In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the :smiley: icon to the top-right).

• 👍️ if you need this to be able to use Mailu. Ideally, you’d also be able to test this on your installation, and provide feedback …
• 🎉 if you find it a nice bonus, but no deal-breaker
• 🚀 if you want to work on it yourself!
  We want to keep this voting open for 2 weeks from now, so please help out!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Nebukadneza]

Hi There,

we see this issue had only little attention 😟. As much as it pains us: In order to get the current issues a bit more manageable for us, we decided to close it. 👋👋

We hope that no one feels offended by doing so. Should the issue get really pressing in the future, please feel free to re-open it.

Thank you for your patience and understanding, 🙇

• Your Mailu Team

[CosmoMyzrailGorynych]

Perhaps a few organizations struck this limit or simply understood the actual cause of a problem (:
Say, Thunderbird asks for a password on such limit errors and says nothing about the original error message. Mailspring does show the original problem and that magical number 20. As people fetch mail, come to work and go home, this limit appears and disappears, becoming seemingly stochastic and driving suspicion away from the server to clients as other accounts work.

We do have such a mailbox that exceededs the number of clients. It is the main organization's email that is actually used by many departments, plus mobile clients, and all the needed mail from dozens of third-party organizations come into it. It is a bad way of organizing mail, but that's what has happened historically.