For anyone searching in the future: The eventual cause turns out to be, as far as I can tell, something screwy in uw-imap or the base64 decode function it uses on this old Solaris server. It seems to be something odd with the number of characters in the hash.

tl;dr I'm going to do my migration with 2 different master users with different length passwords, which will cover all cases and allow me to migrate all the users. Problem solved for this case.

Now the long version for the archive:

To diagnose the problem I eventually wrote a short perl program using IO::Socket::SSL that prints the UW-Imap banner and the '+' second prompt, logs what it receives back, and exits. This let me see that in all cases, doveadm sends the single line AUTHENTICATE command, so that wasn't the problem.

It had never occurred to me to reverse the hash and see what was being sent. I had been testing from telnet / "openssl s_client" using a string "\0user@masteruser\0masterpass" . Doveadm is sending "user\0masteruser\0masterpass" . Different input, different results.

Somewhere in my testing, I forgot to add the -n to

echo -e "\0user@masteruser\-masterpass" | base64

(so the input to base64 had a trailing newline) and to my surprise, a user that didn't work before worked ! That mistake is how I figured out the extra character in the password was somehow making a difference.

So -- since this is a one time migration, and it's repeatable, I've come up with the users that work with the padding, and the ones that work without, and will run the import each way for each list, turn off the legacy server and be done with this !

Thanks for the pointers, and if anyone else runs into this bizare situation hopefully they find this ! Of course if anyone knows why this happens I'd love to hear it.

-Chris

On Wed, 8 Feb 2023, Chris Candreva wrote:

On Wed, 8 Feb 2023, Aki Tuomi wrote:

...

Can you try setting imapc_sasl_mechanisms to login, maybe it works better?

And Stephan Bosch stephan@rename-it.nl wrote:

...

Can you make a protocol log (tcp dump of commands sent by client and replies sent by server) for one of these sessions? e.g. using ngrep if connections aren't secured.

I was using imaps initially. Switching to imap over port 143 to do the tcpdump had the side effect of switching to LOGIN authentication, evidently uw-imap is sending different capability strings. It still doesn't work though. Both from the error and the dump I can tell "doveadm" is sending the user's id only without the "*masteruser" and the master user password.

Plain connection banner:

• OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS] foo.com IMAP4rev1 2007e.404 at Wed, 8 Feb 2023 16:45:22 -0500 (EST)

SSL Banner on 993:

• OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN] foo.com IMAP4rev1 2007e.404 at Wed, 8 Feb 2023 16:53:36 -0500 (EST)

...

...

On 08/02/2023 06:24 EET Chris Candreva chris@westnet.com wrote:

I'm migrating a legacy uw-imap system to Dovecot, on a Rocky (RHEL) 8 server running Dovecot 2.3.16-3 from their repos. I am using a master user to import all users for an imaps connection from the old server to the new. On a trial run however, it worked for about half the users. Half are giving an error of the form:

dsync(user): Error: imapc(host:993): Command '1 AUTHENTICATE PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' failed with BAD: 1 Missing or invalid argument to AUTHENTICATE

I can't seem to get the IMAP command for the users that did work. However, on the face of it, that is an invalid AUTHENTICATE command. If I take that string and brake it up into (what I've googled is) the proper form of multi-command form of

1 AUTHENTICATE PLAIN + xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

then the login succeeds. I have not been able to find anyone else with this problem in my search. Is this a known issue, is there a way to force the multi-line AUTHENTICATE, something else I'm missing ? Any help is appreciate on this!

-Chris

--

======================================================================== Chris Candreva -- chris@westnet.com -- http://www.westnet.com/~chris

--

======================================================================== Chris Candreva -- chris@westnet.com -- http://www.westnet.com/~chris