Ah, hmm, that's unfortunate.

Maybe try again? If the author abandoned the module, though, I have no idea what the best way to proceed would be. Perhaps there is a process for taking over CPAN modules, or some kind of BCP for how to fork them.

Looking at the spec some more, the format of the data returned by FETCH ... RFC822 appears to be equivalent to that returned by FETCH ... BODY[] (p. 78), so a new function that did what you want might be as simple as this (note -- this'd go into Net::IMAP::Client, naturally, not your code):

sub peek_rfc822_body {
    my ($self, $msg) = @_;
    my $wants_many = undef;
    if (ref($msg) eq 'ARRAY') {
        $msg = join(',', @$msg);
        $wants_many = 1;
    }
    my ($ok, $lines) = $self->_tell_imap(FETCH => "$msg BODY.PEEK[]", 
+1);
    if ($ok) {
        my @ret = map { $_->[1] } @$lines;
        return $wants_many ? \@ret : $ret[0];
    }
    return undef;
}
[download]

But this is totally untested, and as stated above, even if it works, I've no idea what the best way of getting that into the module would be.

"If the author abandoned the module, though, I have no idea what the best way to proceed would be. Perhaps there is a process for taking over CPAN modules ..."

The CPAN FAQ has answers to these types of questions. In this instance, the two most relevant seem to be:

• How do I go about maintaining a module when the author is unresponsive?
• How do I adopt or take over a module already on CPAN?

-- Ken

The best way to get that into the module is to send a patch to the module maintainer. The last release was in January this year, which certainly doesn't feel as if the module is unmaintained.

The ideal way to submit a patch is through RT (https://rt.cpan.org/Dist/Display.html?Name=Net-IMAP-Client) for this distribution (as for most) and also a very convenient way to inform others about your intention of change even if the original module author does not implement your change quickly (enough).

The second best way is to send the proposed addition instead of a patch file via the same mechanism.

I haven't looked into the test infrastructure of Net::IMAP::Client, but I figure it does not come with its own IMAP test server, so simply amending whatever tests there are for ->rfc822_body to also call ->peek_rfc822_body and expect the same results feels sensible.

I had thought about making that change but was unsure of the syntax.

I am modifying the package locally and using it.