These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for dovecot dbox on the new forum.
This website is deprecated, and remains online only for historic access to old issues and docs for historic versions of Virtualmin. It has been unmaintained for several years, and should not be relied on for up-to-date information. Please visit www.virtualmin.com instead.
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:
I think it sounds pretty neat, thanks for putting it on my radar.
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).
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.
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
/etc/default/clamassassin
CLAMSCAN=clamdscan
/etc/dovecot/conf.d/10-mail.conf. This is without mail_attachment_dir, so storing attachment within mails.
mail_location = sdbox:~/mail/
/etc/dovecot/conf.d/15-mailboxes.conf
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 } }
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:
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.
--
Check out the forum guidelines!
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.
--
Check out the forum guidelines!
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. https://www.dovecot.org/pipermail/dovecot/2011-June/059855.html
/etc/procmailrc
DROPPRIVS=yes
LOGFILE=/var/log/procmail.log
TRAP=/etc/webmin/virtual-server/procmail-logger.pl
VERBOSE=YES
LOGABSTRACT=YES
LDA="/usr/lib/dovecot/dovecot-lda -d $LOGNAME"
:0fw
| /usr/bin/clamassassin
:0:
* ^X-Virus-Status: Yes
| $LDA -m .infected
EXITCODE=$?
:0fw
| /usr/bin/spamassassin
:0:
* ^X-Spam-Status: Yes
| $LDA -m Junk
EXITCODE=$?
:0:
| $LDA
EXITCODE=$?
:0
* ?/usr/bin/test "$EXITCODE" != "0"
/dev/null
EXITCODE=0
/etc/postfix/main.cf as usual.
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
/etc/default/clamassassin
CLAMSCAN=clamdscan
/etc/dovecot/conf.d/10-mail.conf. This is without mail_attachment_dir, so storing attachment within mails.
mail_location = sdbox:~/mail/
/etc/dovecot/conf.d/15-mailboxes.conf
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
}
}