Viktor Dukhovni via Postfix-users wrote in <z-oqi_yecj-yp...@chardros.imrryr.org>: |On Mon, Mar 31, 2025 at 07:30:03AM +0200, Paul Neuwirth via Postfix-users \ |wrote: | |>> dovecot also nothing about chroot in config |>> cwd and most open files is /var/run/dovecot doesn't seem to be a |>> (ch)root-dir either. |> |> I again think I've got this solved. |> Problem was allegedly very big E-Mails (10-30MiB) in the user's |> mail-file. |> |> I think that would be no issue with mbox format? | |Not a major problem for appending to the mbox, but potentially a big |problem for an updating reader, since annotating messages as read, |deleting a message, and performing other non-append modifications, may |require rewriting much of the content of the mailbox while holding a |lock. | |The "mbox" format is obsolete, and should be avoided.
Regarding the latter, and for a different point of view, i am in a completely other camp. It is, say, a matter of how a user does things. As you say... So stay all with your Maildir, or what your (e)nmh mailers gives to you, if you use that. But all my boxes are MBOX. The Research Unix mail, but, that now aside, even more so the BSD Mail and later Research Unix mail plus the "combined" POSIX mailx center around a primary system mailbox ($MAIL), and a secondary $MBOX. The design idea seems to have been that primary box emails are seen only once, they normally vanish or are moved to the $MBOX -- automatically that is. It can be configured then etc etc, like McIlroy writes in his "A Research UNIX Reader" regarding the mail program: Never satisfied with its exact behavior, everybody touched it at one time or another I personally diversified this a bit in that $MAIL is only for the local system and its cron etc messages. The rest is all in a only temporarily (LID open) fuse-mounted encrypted volume, with folders like "download" etc, which takes the part of $MAIL, so to say. That is read top-down, and stuff is sorted. Heck it is shitty i know, i could also sort into the final locations automatically, and then iterate over all folders to read the new mails therein .. but i do not. Some messages remain in +download longer, but before new downloads are performed this fits well on a single screen. Practically all folders but +download are append-only, read-only. Once a year they are rotated, the old ones stored as YEAR.file.lz (zst in the past). With this approach, that sails pretty nearby the original design, i would think, MBOX is not a problem, especially not on this NVME disc. Granted that +download could also be Maildir, even more so if +download would be $MAIL *and* especially so if that $MAIL would be the domain's $MAIL, ie, where the postfix server stores all incoming messages (append-only). Yet it is not like that. Dovecot in particular supports/ed i think indexed MBOX where the file does not need to be updated each and every time, ie, if messages are removed, and all that. I mean, MBOX is a single-file database, if you have software which treats it like that (dovecot) then why not? It can be even better than Maildir, which effectively puts all the work to the file-, and the operating system. It is only that you do not see it. Having said all that, i do not have such large emails. And even Dovecot switched away from MBOX as default, i think. But MBOX is not obsolete. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
