> ----- 2006g ----- (Mulberry works)
> A00010 LIST "" "a/a2/a3/%/%"
> * LIST () "/" a/a2/a3/a41
> * LIST () "/" a/a2/a3/a42
> A00010 OK LIST completed

If 2006g ever did this, this is definitely a bug.  "a/a2/a3/a41" can not
match "a/a2/a3/%/%", although it could match "a/a2/a3/%".

The correct response is either to return nothing at all, or return
"a/a2/a3/a41/".

> Cyrus Daboo, author of Mulberry, stated:
>> Yes it does look like the trailing slash is the issue. The spec is not at
>> all clear on what it means to have a mailbox with a trailing slash and
>> how it might differ from one without. In theory what the server is doing
>> is perfectly "legal", so this does represent a bug in Mulberry.

Cyrus is right on this; the issue is what, precisely, are the semantics
of hierarchy or are all these just flat names with funny behavior for "%".
These days, the best thing seems to be to take the latter approach.

In imapd, the names with a trailing slash are identical to those without
the trailing slash.  The only difference is that the former match the
wildcard and the latter do not.

>> The
>> trivial fix would be to ensure the trailing slash (or appropriate
>> hierarchy delimiter) is removed from names returned by LIST.

I think that by this, Cyrus means "in Mulberry", because it would
definitely be wrong for imapd to return the names without the trailing
slash.  The only choices, as noted above, are to return the names
without the trailing slash or not to return the names at all.

> I, too, wondered about what the trailing slash means. It appears the
> intention is to make the answer more closely match the format of the
> question.

It isn't a question of "more closely match".  It is a question of "match
at all"!

If there is a directory "a", and a wildcard of "%/%", the question is
whether or not "a" shows up at all in the listing.

"a" does not match "%/%", and can not.  There must be at least one
slash in the returned result to match that pattern.  "a/" matches.

The other choice is not to show any name at all.  So if you do a list
of "%/%" and "a" does not have any children, then you will see no
evidence that "a" exists at all.

> In src/osdep/unix/dummy.c (slightly reformatted here):
> 
> @@ -312,7 +312,7 @@
>               }
>                                 /* try again with trailing / */
>               else if (pmatch_full (path,pat,'/') &&
> -                 !dummy_listed (stream,'/',path,LATT_NOSELECT,contents))
> +                 !dummy_listed (stream,'/',tmp,LATT_NOSELECT,contents))
>                 break;
>             }
>             if (dmatch (path,pat,'/') &&
> 
> This avoids confusing Mulberry, but it probably reintroduces a bug.

Yes, it definitely introduces a bug.  It is returning a string that
does not match the pattern.


_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to