- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Wed, Oct 2
- Set back SWOOLE_PACKAGE_MAX_LENGTH to 10MB
Tue, Oct 1
Yes, the user hr1@os-s.de does not exist in the LDAP. It is not a vaild usser. Therefore no authentication is possible. But this should not be a cause for saslauthd to fail and terminate, am I correct?
The kolab-saslauthd terminates. I reconfigured systemd to automatically restart the daemon because otherwise the login would fail for valid users as well.
as long as I could see, it is still a Domain address issue!
Addressed comments, avoid using the magic 51 status
Looks good, but for consistency both queries should use tenant context and the same way of comparing user status.
Actually the logs continue. Apparently my copy buffer did not copy the complete log. I guess the failed login of hr1 is the last thing of the old process. Then the saslauthd is restarted reading its configuration files:
Mon, Sep 30
Sep 27 2024
Sep 25 2024
The package has been updated; closing this task.
Packaging fix: https://obs.kolabsys.com/request/show/3324
perhaps Domain based issue?
see end of your logs.
In D4950#61803, @machniak wrote:I see that MoveItems has a global Status (that we do not use) and per-item Status. https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-ascmd/acae4033-b4f9-4f2a-8d83-51e097eb3b90
I thought that the common status codes can be used everywhere, but the documentation is not clear. https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-ascmd/95cb9d7c-d33d-4b94-9366-d59911c7a060
As for 110 (server error), it looks like in general it might not be the best default error state as it means "the device SHOULD NOT retry later.". 111 (ServerErrorRetryLater) might be better for most generic error cases.
Addressed comments