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

Owner: PLOBBES [...]
Requestors: gilles.lamiral [...]

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 [...]
From: Gilles LAMIRAL <gilles.lamiral [...]>
Download (untitled) / with headers
text/plain 1.4k
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 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 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
Download mail2world
text/plain 1k

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

Download (untitled) / with headers
text/plain 1.1k
I just checked in the following: 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:

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to