More information =>
http://www.courier-mta.org/imap/README.maildirquota.htmlContents of maildirsizemaildirsize contains two or more lines terminated by newline characters.
The first line contains a copy of the quota definition as used by the system's mail server. Each application that uses the maildir must know what it's quota is. Instead of configuring each application with the quota logic, and making sure that every application's quota definition for the same maildir is exactly the same, the quota specification used by the system mail server is saved as the first line of the maildirsize file. All other application that enforce the maildir quota simply read the first line of maildirsize.
The quota definition is a list, separate by commas. Each member of the list consists of an integer followed by a letter, specifying the nature of the quota. Currently defined quota types are 'S' - total size of all messages, and 'C' - the maximum count of messages in the maildir. For example, 10000000S,1000C specifies a quota of 10,000,000 bytes or 1,000 messages, whichever comes first.
All remaining lines all contain two whitespace-delimited integers. The first integer is interpreted as a byte count. The second integer is interpreted as a file count. A Maildir++ writer can add up all byte counts and file counts from maildirsize and enforce a quota based either on number of messages or the total size of all the messages.
The current implementation of Maildir++ in Courier inserts whitespace padding on each line so that each line (including the terminating \n) is 14 bytes in size. This minimizes the impact of appending-related bugs in some NFS implementations.
Calculating maildirsize
In most cases, changes to maildirsize are recorded by appending an additional line. Under some conditions maildirsize has to be recalculated from scratch. These conditions are defined later. This is the procedure that's used to recalculate maildirsize:
If we find a maildirfolder within the directory, we're delivering to a folder, so back up to the parent directory, and start again.
Read the contents of the new and cur subdirectories. Also, read the contents of the new and cur subdirectories in each Maildir++ folder, except Trash. Before reading each subdirectory, stat() the subdirectory itself, and keep track of the latest timestamp you get.
If the filename of each message is of the form xxxxx,S=nnnnn or xxxxx,S=nnnnn:xxxxx where "xxxxx" represents arbitrary text, then use nnnnn as the size of the file (which will be conveniently recorded in the filename by a Maildir++ writer, within the conventions of filename naming in a Maildir). If the message was not written by a Maildir++ writer, stat() it to obtain the message size. If stat() fails, a race condition removed the file, so just ignore it and move on to the next one.
When done, you have the grand total of the number of messages and their total size. Create a new maildirsize by: creating the file in the tmp subdirectory, observing the conventions for writing to a Maildir. Then rename the file as maildirsize. Afterwards, stat all new and cur subdirectories again. If you find a timestamp later than the saved timestamp, either remove maildirsize and proceed, or repeat the recalculation.
Before running this calculation procedure, the Maildir++ user wanted to know the size of the Maildir++, so return the calculated values. This is done even if maildirsize was removed.
Calculating the quota for a Maildir++This is the procedure for reading the contents of maildirsize for the purpose of determine if the Maildir++ is over quota.
If maildirsize does not exist, or if its size is at least 5120 bytes, recalculate it using the procedure defined above, and use the recalculated numbers. Otherwise, read the contents of maildirsize, and add up the totals.
The most efficient way of doing this is to: open maildirsize, then start reading it into a 5120 byte buffer (some broken NFS implementations may return less than 5120 bytes read even before reaching the end of the file). If we fill it, which, in most cases, will happen with one read, close it, and run the recalculation procedure.
In many cases the quota calculation is for the purpose of adding or removing messages from a Maildir++, so keep the file descriptor to maildirsize open. A file descriptor will not be available if quota recalculation ended up removing maildirsize due to a race condition, so the caller may or may not get a file descriptor together with the Maildir++ size.
If the numbers we got indicated that the Maildir++ is over quota, some additional logic is in order: if we did not recalculate maildirsize, if the numbers in maildirsize indicated that we are over quota, then if maildirsize was more than one line long, or if the timestamp on maildirsize indicated that it's at least 15 minutes old, throw out the totals, and recalculate maildirsize from scratch.
Eventually the 5120 byte limitation will always cause maildirsize to be recalculated, which will compensate for any race conditions which previously threw off the totals. Each time a message is delivered or removed from a Maildir++, one line is added to maildirsize (this is described below in greater detail). Most messages are less than 10K long, so each line appended to maildirsize will be either between seven and nine bytes long (four bytes for message count, space, digit 1, newline, optional minus sign in front of both counts if the message was removed). This results in about 640 Maildir++ operations before a recalculation is forced. Since most messages are added once and removed once from a Maildir, expect recalculation to happen approximately every 320 messages, keeping the overhead of a recalculation to a minimum. Even if most messages include large attachments, most attachments are less than 100K long, which brings down the average recalculation frequency to about 150 messages.
Also, the effect of having non-Maildir++ clients accessing the Maildir++ is reduced by forcing a recalculation when we're potentially over quota. Even if non-Maildir++ clients are used to remove messages from the Maildir, the fact that the Maildir++ is still over quota will be verified every 15 minutes.
Delivering to a Maildir++
Delivering to a Maildir++ is like delivering to a Maildir, with the following exceptions: Follow the usual Maildir conventions for naming the filename used to store the message, except that append ,S=nnnnn to the name of the file, where nnnnn is the size of the file. This eliminates the need to stat() most messages when calculating the quota. If the size of the message is not known at the beginning, append ,S=nnnnn when renaming the message from tmp to new.
As soon as the size of the message is known (hopefully before it is written into tmp), calculate Maildir++'s quota, using the procedure defined previously. If the message is over quota, back out, cleaning up anything that was created in tmp.
If a file descriptor to maildirsize was opened for us, after moving the file from tmp to new append a line to the file containing the message size, and "1".
Reading from a Maildir++Maildir++ readers should mind the following additional tasks:
Make sure to create the maildirfolder file in any new folders created within the Maildir++.
When moving a message to the Trash folder, append a line to maildirsize, containing a negative message size and a '-1'.
When moving a message from the Trash folder, follow the steps described in "Delivering to Maildir++", as far as quota logic goes. That is, refuse to move messages out of Trash if the Maildir++ is over quota.
Moving a message between other folders carries no additional requirements.
