Skip Menu |

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

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

People
Owner: PLOBBES [...] cpan.org
Requestors: gilles.lamiral [...] laposte.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 3.18
Fixed in: 3.36



Subject: Message set "1:*" is buggy in fetch_hash( "1:*", "RFC822.SIZE", $hash_ref)
Date: Wed, 24 Jun 2015 02:49:45 +0200
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: Gilles LAMIRAL <gilles.lamiral [...] laposte.net>
Hello Phil, Message set "1:*" is buggy in fetch_hash( "1:*", "RFC822.SIZE", $hash_ref) It doesn't work. It does UID FETCH 1: (* RFC822.SIZE ) instead of UID FETCH 1:* ( RFC822.SIZE ) For example, the following code is buggy in 3.35 print "==== fetch_hash\n" ; my $hashref = {} ; $imap->fetch_hash( "1:*", "RFC822.SIZE", $hashref ) ; The fix is easy, just permit the * in sub fetch_hash() when considering the message set. sub fetch() does not have this bug. gilles@petite:~/public_html/imapsync/W/Mail-IMAPClient-3.35/lib/Mail 54$ diff IMAPClient.pm-3.35 IMAPClient.pm 2151c2151 < elsif ( $words[0] =~ s/^([,:\d]+)\s*// ) { --- Show quoted text
> elsif ( $words[0] =~ s/^([,:\d\*]+)\s*// ) {
Attached is a full example to show and fix this bug. It's called mail2world because I'm patching imapsync to allow a successful sync with the weird IMAP4 Mail2World 2.6 server. By the way a documentation example is wrong about fetch_hash http://search.cpan.org/~plobbes/Mail-IMAPClient-3.35/lib/Mail/IMAPClient.pod#fetch_hash my $hashref = {}; $imap->fetch_hash( "RFC822.SIZE", $hashref ); print "Msg #$m is $hashref->{$m} bytes\n" foreach my $m (keys %$hashref); In this example $hashref->{$m} should be instead $hashref->{$m}->{'RFC822.SIZE'} to print each message size. Thanks in advance Phil! Have a nice week. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06

Message body is not shown because sender requested not to inline it.

I just checked in the following: https://github.com/plobbes/mail-imapclient/commit/f2d2603239c1a470db78c0b5e0c1e932395c1881 There's also a documentation update, but that will be in a later commit. This fix will be in the next release. With this change, I modified fetch_hash such that it no longer tries to be (overly) smart about what data should be in the hashes of data returned from the server. The only "filtering" that is left is that the UID will not be in the hash unless the caller has explicitly requested the UID in the results from the server (this should be consistent with original behavior). In theory this shouldn't affect most use cases (and not any "normal" use cases). In a worse case scenario the returned hash will have more data than originally requested, basically whatever the IMAP server decided should be returned for the request. In general, I'll expect that the server knows what it is doing, and we really shouldn't try to be overly smart in this case. FWIW, I'm hopeful that this change actually makes life better for CiderWebmail as they've hit issues related to this in the past: https://github.com/CiderWebmail/CiderWebmail/pull/30