#2379 size of mailbox (Maildir) reported is not correct


webmin ver: 1.250
perl: 5.8.6
postfix: 2.2.2-2

When using Maildir/ with postfix, the Read User Mail
reported storage size of the user's
"/home/username/Maildir" is incorrect.

I have tried these two Read User Mail module settings:

Detect location of mail files automatically? "Yes,
based on mail server" -- Mail server installed -> Postfix
"No, use settings below .."
All set to "None" except
"Mail directory in user home directories" set to "Maildir/"

But configurations result in the reporting of a really
small "kb"s.

I see that mailboxes-lib.pl in "sub
mailbox_folder_size" calcs from the $_[0]->{'type'}.
Perhaps it should think it's a "1" for qmail maildir?
(but of course changing the "Mail server installed" to
"Qmail" makes it barf at the fact that Qmail is really
not installed).

Should there be a "Postfix + Maildir" option and a new
$_[0]->{'type'} devised to support correct calc of the

Jamie, give me a suggestion and I can see what I can
patch together (post reply/suggestion in this bug report).


  • Nobody/Anonymous

    Logged In: NO

    Thinking out-loud:

    home_mailbox = Maildir/

    If home_mailbox ends in a slash, then postfix knows it is a
    Maildir/ (really, no matter what the name of the "Maildir"
    part is).

    In the "Local delivery" portion of the Postfix module, there
    is the field named "Home-relative pathname of user mailbox
    file". If the folders-lib.pl section could test for a
    trailing "/" in that field, then it should use the
    qmail-like subroutine "mailbox_folder_size" found in
    folders-lib.pl. To get that to happen, the $_[0]->{'type'}
    has to be == 1. Now, what sets the $_[0]->{'type'} value?

  • Nobody/Anonymous

    Logged In: NO

    In the postfix module, postfix-lib.pl there is a subroutine
    named "postfix_mail_system" and it:

    # Returns 0 and the spool dir for sendmail style,
    # 1 and the mbox filename for ~/Mailbox style
    # 2 and the maildir name for ~/Maildir style

    The folders-lib.pl subroutine "mailbox_folder_size" should
    test (and not assume?) that even though it is postfix, it
    needs to determine if postfix is using 0,1 = mbox or 2 = for

    Am I on the right track, Jamie?

  • Jamie Cameron

    Jamie Cameron - 2006-01-02

    Logged In: YES

    I tested this on my system, and it reported the message
    sizes correctly.
    Are you always seeing the same low size of each mailbox?
    Do the Maildir directories have the actual mail files under
    cur and new ?

    By the way, mailbox_folder_size is not used in this case ..
    it returns the number of messages in the folder, not their
    size on disk. Instead, it is the folder_size function that
    does the work.

  • Nobody/Anonymous

    Logged In: NO

    This account is using IMAP and the user has created folders
    using their IMAP client (could be through Thunderbird
    [remote client] or through Horde/IMP).

    # du
    4 ./Maildir/tmp
    4 ./Maildir/.spam/tmp
    60 ./Maildir/.spam/new
    4 ./Maildir/.spam/cur
    72 ./Maildir/.spam
    3256 ./Maildir/new
    4 ./Maildir/cur
    28 ./Maildir/.INBOX
    4 ./Maildir/.woody/tmp
    4 ./Maildir/.woody/new
    4 ./Maildir/.woody/cur
    16 ./Maildir/.woody
    4 ./Maildir/.Sent/tmp
    6692 ./Maildir/.Sent/new
    4 ./Maildir/.Sent/cur
    6732 ./Maildir/.Sent
    10124 ./Maildir
    10128 .

    The Read User Mail reports:
    adam (2916 kB)

    ...and through Virtualmin it reports "Mail file size: 2915 kB"

    It appears it is not reading the entire "Maildir/"

  • Jamie Cameron

    Jamie Cameron - 2006-01-03

    Logged In: YES

    OK, that explains the problem .. Webmin isn't currently
    taking those extra files created by IMAP into consideration.
    The next release will fix this though..

  • Jamie Cameron

    Jamie Cameron - 2006-01-03
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks