Skip Menu |

This queue is for tickets about the Mail-IMAPClient CPAN distribution.

Report information
The Basics
Id: 68648
Status: resolved
Priority: 0/
Queue: Mail-IMAPClient

People
Owner: PLOBBES [...] cpan.org
Requestors: stef [...] bgs.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 3.29



Subject: [patch]: CAPABILITY after authenticate
Date: Sat, 4 Jun 2011 19:02:56 +0200
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: Stef Simoens <stef [...] bgs.org>
Hello, I was using imapsync (which uses Mail::IMAPClient as you probably know). I was a bit surprised that, when trying to migrate between two Dovecot-2.0.13-installations, I got the error message that "NAMESPACE" was not supported... I learned that dovecot server sends "upgraded" capabilities after authentification (I think some other servers do too). There are three solutions: - not reading the new CAPABILITIES, letting the user give --prefix and --sep - interpreting the new CAPABILITIES sent by the server after authentication (this would be the clean way) - invalidating the CAPABILITIES after authentication (this would be the easy way) I went for the easy way; and wrote a little patch that applies to Mail::IMAPClient 3.25 (I know that the latest version is 3.28 but I didn't see anything in the Changelog about this) (PS: the $self at the end of sub login {}, shouldn't that be 'return $self', as at the end of sub authenticate {} ?) Kind regards, Stef Simoens --- /usr/lib64/perl5/vendor_perl/5.12.3/Mail/IMAPClient.pm~ 2011-06-04 15:26:25.000000000 +0200 +++ /usr/lib64/perl5/vendor_perl/5.12.3/Mail/IMAPClient.pm 2011-06-04 18:43:33.767007213 +0200 @@ -452,7 +452,11 @@ $self->_imap_command("LOGIN $id $passwd") or return undef; + # get new capabilities after authentication + delete $self->{CAPABILITY}; + $self->State(Authenticated); + $self; } @@ -3207,6 +3211,9 @@ Authen::NTLM::ntlm_reset() if $scheme eq 'NTLM'; + # get new capabilities after authentication + delete $self->{CAPABILITY}; + $self->State(Authenticated); return $self; }
Stef, thank you for taking the time to report this bug. This is one of those issues I've known I should update for a while, but somehow never got around to it so thanks for the push to get this fixed! Show quoted text
> I learned that dovecot server sends "upgraded" capabilities after > authentification (I think some other servers do too).
Definitely. Show quoted text
> There are three solutions: > - not reading the new CAPABILITIES, letting the user give --prefix and > --sep > - interpreting the new CAPABILITIES sent by the server after > authentication (this would be the clean way) > - invalidating the CAPABILITIES after authentication (this would be > the easy way)
I like the easy way in this case. I may take a slightly different tack for the final patch. I'm thinking about anytime State() is set to Authenticated I'll delete the cached capabilities, but do that by making the State method a valid/first-class method. That avoids a little bit of code duplication and catches the case regardless of when/where it happens in the code. Show quoted text
> I went for the easy way; and wrote a little patch that applies to > Mail::IMAPClient 3.25 (I know that the latest version is 3.28 but I > didn't see anything in the Changelog about this) > (PS: the $self at the end of sub login {}, shouldn't that be 'return > $self', as at the end of sub authenticate {} ?)
In Perl, functionally, it doesn't matter really, but putting the return in there would probably be best for clarity. I'll look to have this bug fixed in the next release!
Mail::IMAPClient 3.29 was released today with the patch for this bug, please feel free to reopen if you find the problem still exists in this release.