Szerző: Phil Pennock Dátum: Címzett: David Chait CC: Exim Users List Tárgy: Re: [exim] Using Routing, Maildir and MBOX for email backups
On 2009-06-10 at 09:55 -0700, David Chait wrote:
[ Mike Cardwell wrote: ] >> That sounds fine to me. However, one recommendation I'd make is to use
>> maildir for the backup as well as the live mail instead of mbox. That
>> way you can easily delete mail from your backup over a certain age. Eg,
>> to delete everything over 30 days (untested): > It really depends on the mail server in question, cyrus-imap would break
> if you simply deleted the file as the folder indexes would become out of
> sync.
Mike said maildir. Cyrus does not use Maildir. They are different
storage formats.
There is a similarity in that there is one file per email and the
content of the files is fairly similar, since it's the natural format.
That's about as far as the similarities go.
Maildir has three sub-directories under the directory corresponding to a
folder, "cur/", "new/" and "tmp/" if memory serves, and procedures for
how mail is created and moved around using those directories, such that
the locking is moved into the filesystem metadata which has good sides
and bad sides, depending upon scale and architecture. It scales well
enough for many people. Sub-folders use directory names starting with a
dot, IIRC.
Cyrus uses a format where the directory which is the mail-folder names
the emails "1.", "2.", etc and uses files starting "cyrus." for things
like indices, caches, full body search corpora, etc and maintains
per-user read state in a separate area entirely. Sub-folders are just
directories with the same name, IIRC.
With Maildir, if you have the mail and know which directory it came
from, you have the backup. With Cyrus's storage format, you don't.
Maildir is intended to be an open format, used by multiple pieces of
software, whereas Cyrus's storage is an internal implementation detail.
All that said, I use Cyrus. But Mike's assertion of Maildir behaviour
is not invalidated by anything Cyrus does differently.
-Phil