[Dovecot] Allowing tilde at start of mailbox names
pod
pod at herald.ox.ac.uk
Wed Jul 25 19:13:15 EEST 2007
>>>>> "TS" == Timo Sirainen <tss at 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.
More information about the dovecot
mailing list