Bug #65770 for Mail-IMAPClient: PLAIN Login: Order of login data not accepted by Dovecot

Wed Feb 16 04:54:22 2011 foss-ml [...] wm1.at - Ticket created

Subject:

PLAIN Login: Order of login data not accepted by Dovecot

I'm trying to use Mail::Box to migrate some mails from thunderbird to an IMAP Server running Dovecot, so Mail::IMAPClient acts as Transport. I can log in on this server with thunderbird, but not with Mail::IMAPClient. The problem is that dovecot expects the username in the base64 encoded login string on the second position, not on the first. (Found by wireshark) I've now changed the resposible code for the plain login to elsif ( $scheme eq 'PLAIN' ) { # PLAIN SASL $response ||= sub { my ( $code, $client ) = @_; encode_base64( chr(0) . $client->User . chr(0) . $client->Password, '' ); }; } which works against dovecot. I'm not sure whether this is a general fix (except that $client->Proxy might be re-added on first position), but I would interpret RFC 4616, Section 2, first paragraph that way.

Thu Feb 17 11:01:43 2011 phil [...] perkpartners.com - Correspondence added

Subject:	Re: [rt.cpan.org #65770] PLAIN Login: Order of login data not accepted by Dovecot
Date:	Thu, 17 Feb 2011 11:01:26 -0500
To:	bug-Mail-IMAPClient [...] rt.cpan.org
From:	Phil Pearl (Lobbes) <phil [...] perkpartners.com>

That fix breaks use of Proxy. Of course the way the module uses the name Proxy is confusing too... RFC 4616 has this syntax: message = [authzid] UTF8NUL authcid UTF8NUL passwd In Mail::IMAPClient, Proxy (if used) becomes 'authcid'. This means: - with Proxy: message = join( chr(0), User, Proxy, Passwd ) - without Proxy was (BUGGY/WRONG): message = join( chr(0), '', User, Passwd ) - without Proxy it should be (as you suggest!): message = join( chr(0), User, Passwd ) With the following I think we get it right (untested): elsif ( $scheme eq 'PLAIN' ) { # PLAIN SASL $response ||= sub { my ( $code, $client ) = @_; encode_base64( # [authname] user password join( chr(0), $client->User, ( defined $client->Proxy ? $client->Proxy : () ), $client->Password, ), "" ); }; } Any chance you could you test and verify this works for you? Thanks! Phil

Thu Feb 17 11:01:44 2011 The RT System itself - Status changed from 'new' to 'open'

Thu Feb 17 13:04:40 2011 foss-ml [...] wm1.at - Correspondence added

From:

foss-ml [...] wm1.at

Show quoted text

> message = [authzid] UTF8NUL authcid UTF8NUL passwd

... Show quoted text

> - without Proxy was (BUGGY/WRONG): > message = join( chr(0), '', User, Passwd ) > > - without Proxy it should be (as you suggest!): > message = join( chr(0), User, Passwd )

Unfortunately, your patch did not work. You need the leading UTF8NUL if Proxy is not given. Attached patch works for me and should work for Proxy being given, but I can't test the latter case. Best Regards Willi Mann

Subject:

authplain_user_vs_proxy.diff

--- /tmp/IMAPClient.pm 2011-02-17 18:55:18.000000000 +0100 +++ /usr/share/perl5/Mail/IMAPClient.pm 2011-02-17 18:58:58.000000000 +0100 @@ -3141,9 +3141,9 @@ $response ||= sub { my ( $code, $client ) = @_; encode_base64( - $client->User + $client->Proxy . chr(0) - . $client->Proxy + . $client->User . chr(0) . $client->Password, ''

Thu Feb 17 14:42:50 2011 PLOBBES [...] cpan.org - Correspondence added

Thanks for the follow up and catching my mistake! I'll have this patched in the next release. FWIW, here's the final code I settled on: elsif ( $scheme eq 'PLAIN' ) { # PLAIN SASL $response ||= sub { my ( $code, $client ) = @_; encode_base64( # [authname] user password join( chr(0), defined $client->Proxy ? ( $client->User, $client->Proxy ) : ( "", $client->User ), defined $client->Password ? $client->Password : "", ), ); }; }

Thu Feb 17 14:42:51 2011 PLOBBES [...] cpan.org - Status changed from 'open' to 'patched'

Sat Mar 05 00:28:32 2011 PLOBBES [...] cpan.org - Fixed in 3.28 added

Sat Mar 05 00:28:32 2011 PLOBBES [...] cpan.org - Broken in 3.00 added

Sat Mar 05 00:28:32 2011 PLOBBES [...] cpan.org - Correspondence added

Mail::IMAPClient 3.28 was released today with the patch for this bug!

Sat Mar 05 00:28:32 2011 The RT System itself - Status changed from 'patched' to 'open'

Sat Mar 05 00:28:34 2011 PLOBBES [...] cpan.org - Status changed from 'open' to 'resolved'