>>>>> "TS" == Timo Sirainen <[EMAIL PROTECTED]> writes:
TS> It's mostly there just to make sure that ~/ or ~user/ can't be TS> used to open mailboxes where you weren't supposed to have access TS> to. I didn't think anyone would really want to have mailboxes TS> beginning with ~. Do you really want them? (I don't think they TS> were possible with UW-IMAP either?) Unfortunately yes it would be useful in my case to have them because of historical accident. UW-IMAP does in fact allow it but maybe only if one is using particular build-time options such as blackBoxDir; I forget the precise details. Suffice to say at some point users were erroneously told to configure clients with '~/mail' as a prefix and this in combination with the particular UW-IMAP build options means we have users with folder hierarchies beginning "~/mail" ('~' uninterpreted). I don't think I can work around this with a hidden namespace since a client subsequently configured not to use a prefix will be used to seeing folders under "~/mail" ('~' uninterpreted). I'm (increasingly forlornly it seems) attempting to migrate with no user visible change. >> Why is it not possible to have mailbox names that begin with '~' >> but without '~' carrying any special meaning? TS> That's what the code does if you don't have TS> mail_full_filesystem_access=yes, but I thought I'd prevent this in TS> no case just in case of a bug somewhere, possibly even outside of TS> Dovecot itself. I appreciate your reasoning regarding bugs elsewhere. I was, however, hoping to introduce a mode of behaviour that would allow me to accept the risk. I'm not using virtual users; every login runs under its own uid so I still have filesystem permissions as a reasonable fall back. TS> There are too many settings TS> already. mail_full_filesystem_access=no should be enough for this. I completely understand why you want to keep the number of setting down. My motivation for introducing a new setting was a vain hope that allowing uninterpreted (*name == '~') behaviour could go into the 1.0 codebase but without also changing the meaning of mail_full_filesystem_access=no in existing deployments.