Re: imap4d LIST and DELETE

[Sergey Poznyakoff]

>       a00 LIST "" #comp.os.*
> 
> To have the entire comp.os hierarchy newsgroup.  Or the imapd server
> could be on top of an SQL db, so:
> 
>       a00 LIST "/" *
> 
> may make sense.
Sure, but for unix filesystem, I suppose, we would better be more
cautious. Rfc states that:

      Server implementations are permitted to "hide" otherwise
      accessible mailboxes from the wildcard characters, by preventing
      certain characters or names from matching a wildcard in certain
      situations.  For example, a UNIX-based server might restrict the
      interpretation of "*" so that an initial "/" character does not
      match.

Since imap4d/list.c is currently oriented only on filesystem-based
mailboxes, we can make use of this statement and prevent user
from seeing mailboxes whose full path does not end in or under
his homedir. Or better yet, list_file() could check the ownership and
list only files owned by the user. What do you think?

> We could restrict CREATE/DELETE/RENAME etc ... to /home/user/Mail/*
> when accessing the filesystem?  But is that the right approach ?
> is it not to restrictive?  Is there an actual benifice/advantage?
Well, it sounds reasonable enough... The actual advantage is
preventing the user from accidental (or even premeditated)
destruction of other files. And we are still conforming to the rfc:
it does not even define what the "mailbox" is, so it is completely
implementation-dependent.

After all, these are the implementation details: I believe that
for the end user it doesn't make much difference how exactly
commands like, say

     a001 LIST "~/drafts" "*"

are mapped onto the server filesystem contents, what does matter for
him is to get the proper functionality. From the other hand, the
`/home/user/Mail' approach is much more safer...


Cheers,
Sergey