"TS" == Timo Sirainen tss@iki.fi 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.