Suggested feature and contribution
Bron Gondwana
brong at fastmailteam.com
Thu Jul 18 20:09:24 EDT 2019
On Thu, Jul 18, 2019, at 19:09, Egoitz Aurrekoetxea wrote:
> Good morning,
>
> When using delete_delayed if someone removes a big folder (that one with more than 20 subfolders anywhere below it) in mboxlist_delayed_deletemailbox() only last 20 are preserved. We think it could be a good idea to preserve all and to have a parameter for configuring it. The reason for that, is that we use delete_delayed for storing the removed content remotely with the customer hired retention period in slow disk space. Perhaps could be a good idea something like :
>
> In mboxlist_delayed_deletemailbox() :
>
> *If (!preserve_delete_delayed_folders_always)*
> *{*
> /* keep the last 19, so the new one is the 20th */
> for (i = 0; i < (int)existing.count - 19; i++) {
> const char *subname = strarray_nth(&existing, i);
> syslog(LOG_NOTICE, "too many subfolders for %s, deleting %s (%d / %d)",
> newname, subname, i+1, (int)existing.count);
> r = mboxlist_deletemailbox(subname, 1, userid, auth_state, NULL, 0, 1, 1,
> keep_intermediaries);
> if (r) goto done;
> }
> *}*
Hmm.... yeah, OK. This is actually buggy in that case! The intended behaviour was to avoid a Denial of Service attack where you would create and delete the same mailbox name millions of times - however, the whole concept is bogus because there's nothing stopping somebody creating and deleting folder000001 through folderFFFFFF and creating the same attack.
I suggest that we just remove this whole silly check entirely, and if we want a similar level of attack protection we do something smarter like a quota for total folders+deleted folders that haven't been cleaned up yet - set it high enough that anybody hitting that is clearly doing something wrong, and require the administrator semi-manually clean up the deleted folders in order to re-allow folder creation.
Cheers,
Bron.
--
brong at fastmailteam.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190719/3f724840/attachment.html>
More information about the Info-cyrus
mailing list