dovecot dbox

Want to save some space on multiple attachments. Is there a way for Virtualmin to use dbox format instead of mbox or maildir?

Good question.

We don’t currently have support in any of our mailbox reading modules for the format…but we don’t actually need it in most places because Usermin is configured to use IMAP to read mail by default.

There will be some features that wouldn’t work, however…the ability for root (or domain owners) to read mail would no longer work, I would think (I can’t tell from a brief reading of the docs if this format is at all backward compatible with Maildir or mbox…it seems like an amalgamation of both plus new indexes).

In short:

  1. I think it sounds pretty neat, thanks for putting it on my radar.
  2. Some features (that require the ability to read/edit the maildir directly) will not work, but I think core features would still be fine with dbox. Usermin can use IMAP (or POP3) to interact with user mail boxes, and that is the default in a Virtualmin install (but not in a stock Usermin install…it would need to be configured to do so in that case).
  3. I would strongly recommend you test thoroughly before switching a production system. It’s been a few years since I did any development on the mail stack, and I may be misremembering places where we depend on mail being in Maildir spools. But, we originally designed the system not to care and to be agnostic about whether mail was in mbox, Maildir, or even…umm mbx, maybe? Some other old format.

Let us know what you find out! If it is more performant (as the docs suggest), I’d be open to making it the default in the future. I’m always open to ways to make the mail stack more efficient. These days mail is more demanding of system resources than the web stack in a lot of deployments (mostly because of ClamAV), and that’s just stupid.

I mean not just read user mail, but also administering mail boxes by Virtualmin. I guess Virtualmin Procmail Wrapper won’t deliver mail to dbox. Yet setting Postfix to deliver directly to Dovecot would mean complete bypass of Virtualmin?

Oh, yeah, procmail would be an issue. But, a little bit of googling indicates you can use the dovecot “deliver” command, which I guess it what you’re suggesting. I haven’t tried it, however, so can’t really give any guidance on how well it works, or if there are any gotchas. I would assume that as long as it is the last thing in the procmail recipe, it’d still be able to do all the stuff virtualmin does with procmail (virus/av/forward/autoreply/etc).

Try it out, and let me know what happens!

I’d eventually like to implement delivery options that leave out procmail, but it does so much and with so much flexibility that it’d be hard to replace it with just one thing.

Well, i managed it to deliver to dbox, but… Its attachment capabilities appeared to be working only with virtual users, as it sets 600 permission to attachment files. So you getting error reading hash file when trying to deliver a mail with same attachment. Even group can’t access them.

I’ve found this 6-year old thread on this.

/etc/procmailrc DROPPRIVS=yes LOGFILE=/var/log/procmail.log TRAP=/etc/webmin/virtual-server/ VERBOSE=YES LOGABSTRACT=YES

LDA="/usr/lib/dovecot/dovecot-lda -d $LOGNAME"

| /usr/bin/clamassassin

  • ^X-Virus-Status: Yes
    | $LDA -m .infected
    | /usr/bin/spamassassin
  • ^X-Spam-Status: Yes
    | $LDA -m Junk
    | $LDA
  • ?/usr/bin/test “$EXITCODE” != “0”

/etc/postfix/ as usual.

mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME



/etc/dovecot/conf.d/10-mail.conf. This is without mail_attachment_dir, so storing attachment within mails.

mail_location = sdbox:~/mail/

namespace inbox {

These mailboxes are widely used and could perhaps be created automatically:

mailbox Drafts {
auto = subscribe
special_use = \Drafts
mailbox Junk {
auto = subscribe
special_use = \Junk
mailbox Trash {
auto = subscribe
special_use = \Trash
mailbox Sent {
auto = subscribe
special_use = \Sent
mailbox “.infected” {
auto = create