doveadm sending invalid AUTHENTICATE to uw-imap

[Chris Candreva]

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 at 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 at 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 at 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 at 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 at westnet.com  --  http://www.westnet.com/~chris
> > 
> 
> 

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