Bug in FETCH request?

Bug in FETCH request?

[Augusto Stoffel]

Hi,

The following request querying the latest message id fails on
public-inbox.org

   curl 'imaps://:@public-inbox.org/inbox.comp.mail.public-inbox.meta.0'\
     -X 'FETCH * (UID)'

It works on other IMAP servers and AFAICT is allowed by the protocol
spec.

This on the other hand works, but you need to choose a high enough
number...

   curl 'imaps://:@public-inbox.org/inbox.comp.mail.public-inbox.meta.0'\
     -X 'FETCH 999999:* (UID)'

[PATCH] imap: allow bare `*' in range

[Eric Wong]

Augusto Stoffel <arstoffel@gmail.com> wrote:
> The following request querying the latest message id fails on
> public-inbox.org
> 
>    curl 'imaps://:@public-inbox.org/inbox.comp.mail.public-inbox.meta.0'\
>      -X 'FETCH * (UID)'
> 
> It works on other IMAP servers and AFAICT is allowed by the protocol
> spec.
>
> Subject: Re: Bug in FETCH request?

Yup, that's a bug, fix below (deployed to public-inbox.org)
Thanks for reporting it since I've been stuck on tougher
data design problems :x

> This on the other hand works, but you need to choose a high enough
> number...
> 
>    curl 'imaps://:@public-inbox.org/inbox.comp.mail.public-inbox.meta.0'\
>      -X 'FETCH 999999:* (UID)'

Right, IIRC that was explicitly in a RFC 3501 example,
whereas a bare `*' wasn't used as an example
(and I didn't check the BNF carefully enough).

Curious, did you discover this on a certain real-world IMAP client?

------8<------
Subject: [PATCH] imap: allow bare `*' in range

I missed that a bare `*' is an allowable seq-number for IMAP
for the number of the latest message in a given mailbox.

Reported-by: Augusto Stoffel <arstoffel@gmail.com>
Link: https://public-inbox.org/meta/87jzdzguml.fsf@gmail.com/
---
 lib/PublicInbox/IMAP.pm | 5 ++++-
 t/imapd.t               | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/PublicInbox/IMAP.pm b/lib/PublicInbox/IMAP.pm
index 378a0363..74249784 100644
--- a/lib/PublicInbox/IMAP.pm
+++ b/lib/PublicInbox/IMAP.pm
@@ -88,7 +88,7 @@ for my $att (keys %FETCH_ATT) {
 }
 undef %FETCH_NEED;
 
-my $valid_range = '[0-9]+|[0-9]+:[0-9]+|[0-9]+:\*';
+my $valid_range = '[0-9]+|[0-9]+:[0-9]+|[0-9]+:\*|\*';
 $valid_range = qr/\A(?:$valid_range)(?:,(?:$valid_range))*\z/;
 
 sub do_greet {
@@ -697,6 +697,9 @@ sub range_step ($$) {
 		# just let the caller do an out-of-range query if a single
 		# UID is out-of-range
 		++$beg if ($beg <= $uid_base || $end > $uid_end);
+	} elsif ($range eq '*') {
+		$beg = $end = $self->{ibx}->over(1)->max;
+		uid_clamp($self, \$beg, \$end);
 	} else {
 		return 'BAD fetch range';
 	}
diff --git a/t/imapd.t b/t/imapd.t
index 549b8766..27c46e54 100644
--- a/t/imapd.t
+++ b/t/imapd.t
@@ -174,7 +174,7 @@ is_deeply(scalar $mic->flags('1'), [], '->flags works');
 	is_deeply($ret, {}, "out-of-range UID FETCH $r");
 }
 
-for my $r ('1:*', '1') {
+for my $r ('1:*', '1', '*') {
 	$ret = $mic->fetch_hash($r, 'RFC822') or BAIL_OUT "FETCH $@";
 	is_deeply([keys %$ret], [1]);
 	like($ret->{1}->{RFC822}, qr/\r\n\r\nThis is a test/, 'read full');

Re: [PATCH] imap: allow bare `*' in range

[Augusto Stoffel]

On Wed, 23 Oct 2024 at 09:30, Eric Wong wrote:

> Augusto Stoffel <arstoffel@gmail.com> wrote:
>> The following request querying the latest message id fails on
>> public-inbox.org
>> 
>>    curl 'imaps://:@public-inbox.org/inbox.comp.mail.public-inbox.meta.0'\
>>      -X 'FETCH * (UID)'
>> 
>> It works on other IMAP servers and AFAICT is allowed by the protocol
>> spec.
>>
>> Subject: Re: Bug in FETCH request?
>
> Yup, that's a bug, fix below (deployed to public-inbox.org)
> Thanks for reporting it since I've been stuck on tougher
> data design problems :x

Thanks!

>> This on the other hand works, but you need to choose a high enough
>> number...
>> 
>>    curl 'imaps://:@public-inbox.org/inbox.comp.mail.public-inbox.meta.0'\
>>      -X 'FETCH 999999:* (UID)'
>
> Right, IIRC that was explicitly in a RFC 3501 example,
> whereas a bare `*' wasn't used as an example
> (and I didn't check the BNF carefully enough).
>
> Curious, did you discover this on a certain real-world IMAP client?

I'm writing an IMAP client and in my situation "FETCH *" seemed to be
the easiest way to find out how many messages a mailbox contains.  (For
some specific reasons I didn't want to use the response of SELECT).  I
still find it funny that you can't say "please fetch the 50 most recent
messages" with one single request...