Special chars in password are not correctly handled by IMAP connection to Exchange through perdition

Steps to reproduce

1. Configure a mail account with the password "défaut" (note the accent on the 'e')
2. Try to sync mail into Nextcloud

Expected behavior

Nextcloud Mail App should be able to sync mail like other client (Thunderbird, SnappyMail...)

Actual behavior

Cannot sync account : imap server says "Fatal Error reading authentication information from client"

Mail app version

2.1.2

Mailserver or service

Exchange through perdition imap proxy

Operating system

Debian 11

PHP engine version

PHP 8.0

Web server

Apache (supported)

Database

MariaDB

Additional info

We had the very same bug with SnappyMail Client, it is documented here : https://github.com/the-djmaze/snappymail/issues/382

It seems to be related to the utf8 encoding of the password.
All accounts with regular passwords (no special chars) works fine with the same configuration.

Full perdition log of a failing auth :

Nov 23 11:14:07 cloud perdition.imaps[2149306]: Connect:  127.0.0.1:50288->127.0.0.1:993
Nov 23 11:14:07 cloud perdition.imaps[2149306]: SSL connection using TLS_AES_256_GCM_SHA384
Nov 23 11:14:07 cloud perdition.imaps[2149306]: username_add_domain: username_add_domain 0 1
Nov 23 11:14:07 cloud perdition.imaps[2149306]: getserver: do_dbserver_get
Nov 23 11:14:07 cloud perdition.imaps[2149306]: SSL connection using ECDHE-RSA-AES256-SHA
Nov 23 11:14:07 cloud perdition.imaps[2149306]: subject: /CN=exchsrv
Nov 23 11:14:07 cloud perdition.imaps[2149306]: issuer: /CN=exchsrv
Nov 23 11:14:07 cloud perdition.imaps[2149306]: username_add_domain: username_add_domain 0 4
Nov 23 11:14:10 cloud perdition.imaps[2149306]: Auth: 127.0.0.1:50288->127.0.0.1:993 client-secure=ssl authorisation_id=NONE authentication_id="failing_user" server="10.30.50.5:993" protocol=IMAP4S server-secure=ssl status="failed: Re-Authentication Failure"

Full perdition log of a working account :

Nov 23 11:16:17 cloud perdition.imaps[2149441]: Connect:  127.0.0.1:41230->127.0.0.1:993
Nov 23 11:16:17 cloud perdition.imaps[2149441]: SSL connection using TLS_AES_256_GCM_SHA384
Nov 23 11:16:17 cloud perdition.imaps[2149441]: username_add_domain: username_add_domain 0 1
Nov 23 11:16:17 cloud perdition.imaps[2149441]: getserver: do_dbserver_get
Nov 23 11:16:17 cloud perdition.imaps[2149441]: SSL connection using ECDHE-RSA-AES256-SHA
Nov 23 11:16:17 cloud perdition.imaps[2149441]: subject: /CN=exchsrv
Nov 23 11:16:17 cloud perdition.imaps[2149441]: issuer: /CN=exchsrv
Nov 23 11:16:17 cloud perdition.imaps[2149441]: username_add_domain: username_add_domain 0 4
Nov 23 11:16:17 cloud perdition.imaps[2149441]: Auth: 127.0.0.1:41230->127.0.0.1:993 client-secure=ssl authorisation_id=NONE authentication_id="working_user" server="10.30.50.5:993" protocol=IMAP4S server-secure=ssl status="ok"

I can't to reproduce this behavior on a recent dovecot imap server so the error may be related to the Exchange server and/or the perdition imap proxy.

Start by reproducing the IMAP authentication failure with the password "défaut" through Exchange and perdition, then compare it with a regular password and a recent Dovecot server. Trace the mail connection and authentication path to identify where the UTF-8 password is mishandled; done means special-character passwords authenticate successfully without regressing regular accounts.