虽然我理解这两种存储格式的基础知识（Maildir下每个邮件1个文件，mbox下每个邮箱1个单个文件），但我想知道这里的实际含义是什么 –
不要pipe理来自postfix的邮箱。 决不。 通过具有适当function的POP / IMAP服务器redirect消息以进行传送。 在dovecot的情况下，dovecot dovecot-lda又名deliver ，可以做任何事情，比如用户控制的邮件过滤，配额pipe理，自动回复等等。
无论如何，由于maibox相对较多的改进，maildir是较新的和可取的格式。 Maildir有一个索引，每个文件夹允许控制重复，到期时间，甚至全文search。 而且，maildir在一大堆消息上速度要快得多。 戴夫科特可以很容易地运行maildir与300k的消息，没有任何明显的减速。 邮箱如此之大本身就是一个问题。 而且，大多数现代的POP / IMAP服务器在大型基础架构中有许多用于常见任务的实用程序。
如果您使用NFS进行邮件存储， 请勿在任何情况下使用mbox。 如果你想要一个可扩展的解决scheme，Maildir是要走的路。
mbox格式的主要问题是文件locking问题 – 如果您有多个邮件服务器，或者多个进程尝试同时访问邮箱，则运行获取损坏的邮箱的风险很大。 通过邮箱删除大量邮件也很困难，例如遇到反弹风暴。
Maildirdevise用于在一台服务器上有多个邮件服务器或多个进程的情况下正常工作，并在IMAP或POP服务器访问该帐户的同时将邮件发送到同一个帐户。
Maildir的主要问题是如果您使用的文件系统在处理太多inode时速度变慢，并且您的备份系统在处理多个文件时效果不佳。 至于文件系统，回来的时候，我做了一个ISP的电子邮件系统pipe理，VXFS是最好的。 对于备份，我没有任何build议。 不幸的是，他们中的大多数似乎被devise来处理数据库服务器，而不是一个巨大的小文件。
后缀不关心，主要是。 它只是将邮件填入某个文件。 当你想通过IMAP（或者POP3）从机器上获取邮件的时候，间隙部分就出现了。 大多数IMAP服务器（我试过）更喜欢Maildirs，因为这些更容易扩展IMAP服务器可能需要的各种元数据，同时仍然保持一个基本的“这是一个Maildir”结构，所以你可以更换IMAP服务器而不会中断太多了（你显然会失去元数据，这也包括邮件标志，所以你应该阅读IMAP服务器的迁移文档，如果你真的想切换）。
search邮箱内的文本并将新邮件附加到邮件文件时，Mbox速度很快，但容易发生邮件损坏，并可能在networking文件系统中遇到问题。 此外，文件locking可能是一个问题。
借助Maildir，检索特定邮件的速度更快，而且由于文件locking或networking文件系统而没有任何问题（例如：使用Maildir，您可以将不同的邮件文件夹存储在不同的NFS共享中，这是使用Mbox无法实现的）。 当文件系统无法有效处理大量文件时，Maildir可能会出现问题。
我知道你需要一个可扩展的解决scheme，在你select一个或另一个之前，一定要给这个文件阅读：（即使你不使用Courier）
基准mbox与maildir
解决具体问题：
一种存储格式比另一种更具扩展性吗？
mbox往往变得越来越难以pipe理。 由于它将所有内容都存储在一个大块中，所以增量式备份可能很难，而且这种访问会在发生时lockingmbox以防写入。 如果存在一些腐败现象，要修复或恢复就更困难了 – 你可以说，存储更多邮件的风险在增加。
Maildir的可扩展性依赖于底层文件系统，因为它将特性地创build许多小文件，每个消息一个。 如果你有很多电子邮件，Maildir通常会更容易，更快速地处理。
数据完整性问题/差异是否存在？
是的，主要的一点是mbox需要在整个存档上进行读/写文件locking，这意味着读取必须等待写入，每个写入必须等待所有其他存取。 如果以无法locking的方式使用（如通过NFS共享），则存档会受到损坏。 任何随机的损坏都可能影响整个存档，而不是一条消息。
使用Maildir，对于大多数操作来说，locking可以处于单个消息的级别，并且任何文件中的损坏只会影响该消息。 消息本身的任何索引都可以根据需要重build。
是否有明确定义的情况下，你应该使用另一种格式？
Maildir正在开始将mbox作为普遍的首选格式，而没有明显的缺点。
它的主要限制是创build了许多许多小文件，这些小文件有能力对某些文件系统造成压力和/或效率低下，这取决于文件系统簇的大小。 这对现代文件系统来说不是一个问题。 它也可以告知您的备份策略，但是总体而言，它为您select备份策略提供了更多的灵活性。