根据我的意愿，有一个邮件服务器在我的照顾下。 很小，〜20个用户。 它工作稳定，不宜更换软件。 并没有必要，但是一旦备份日志明确提示-如果您本着同样的精神继续工作，则整个晚上将进行一次完整备份。 关键在于用户邮箱的数量。
问题表明，有必要解决。 未来的方法-购买功能更强大的铁-不是我的类型，预算也不是橡胶。 显而易见的选择：配额。 但是实际上，这没有太大帮助。 经过仔细检查，“我清洗了一切”的誓言变成了印章，有趣的照片和全家福（在公司邮件中是）。 “我有紧急信号灯不起作用，立即执行”的尖叫声数量增加了一个数量级。 所以不要长久而对人失去信心。
幸运的是，我不是心理学家，不是教练或导师。 我的业务是技术。 因此，我们将从技术角度出发。
我认为的第一件事是自我毁灭的讯息。 粗略地说，没有“重要”标记的所有内容都会在N天后删除。 以我的口味，应该将其“缝制”到电子邮件存储的标准中。 但是到目前为止，事实并非如此，在我看来实施起来也过于雄心勃勃。
第二个想法是副本。 在您不是主要收件人的地方知道这些消息。 来找您只是为了提供信息。 其中某些消息可能会自动删除。 但是，突然之间，用户被划分为两个阵营：“所有人都需要您什么”和“这是什么”。 我没有掌握这种条件的自动排序算法。
好吧，不要删除，所以要复制！ 取出所有副本并进行符号链接。 快速分析表明，即使仅以这种方式处理完整副本，也可以节省三个存储库。 但是，但是，但是。 不幸的是，由于许多技术限制，这是一条死路。
扰流板下感兴趣者的详细信息-并非所有的存档者都了解符号链接；
-服务器软件在某些地方发疯了；
-复杂性组织。 字符和访问权限。
顺便说一句，在我的邮件服务器中，设置和常规备份以及用户的存档存储非常少。 因此，操作空间很小。
还剩下什么？ 带着悲伤，我看着海豹
并想知道已经有一个简单的神经网络可以为用户清除邮件。 然后...打扰一下，打扰一下，但是猫在信里做了什么？ 我记得一封带附件的信比一个附件重近三分之一！ 但是我可以移动附件吗？
这样就开辟了“许多精彩发现”的道路。 如果我知道...嗯，你明白了。 一滴无知和勇气带领我们走向胜利！
所以：我们
将附件与信件分开存储 。
您在这里可能犯的主要错误是在文本编辑器中打开eml文件，并确定其中包含纯文本。 所以我做到了。 很高兴。 现在，我将编写一个批处理文件。 用于提取附件的命令行实用工具已满：副手
github.com/erikvdv1/eml-attachments或
github.com/maiken2051/uudeview 。 编码存在问题，但这不是最重要的事情。
最重要的是：取出文件并创建指向该文件的链接是一件小事。 但是将此链接推送到原始字母中...因为没有文本。 有
MIME 。
当然，一个经验丰富的读者现在对这个不幸的作者感到轻笑。 然而，作者发现了“标准”的乐趣。 我了解的最重要的一点是：沉没木耳的蘑菇不是必需的。
实例和滥用-在剧透情况下：
字符集= utf-8
字符集=“ UTF-8”
字符集=“ UTF-8”
字符集= UTF-8;
charset =“ UTF-8”;
charset =“ UTF-8”;
这是一回事。
在Base64流的中间出现换行符。 它们的来源对我来说仍然是个谜。
反之亦然：标头部分后没有\ r \ n \ r \ n。
在标题本身中，字段的顺序应左脚跟的要求。
较早的字母允许行长不超过80个字符，包括服务字符。
文件名中可能会有换行符（在邮件正文中，而不是在名称本身中）。
通常，换行符可以在任何地方，尽管事实上在标准参数中将换行符声明为当前参数的末尾。
字母本身的文本已编码。 编码的精确程度仍然取决于特定服务器的良心，这里有很多选择（臭味）。
并且，在信中几乎总是有html部分。 也就是说，如果您发送“ Hello”并且有标签br或p，那么在字母中将始终有两个部分：具有简单文本和标签。 和文本是重复的。 在这里，他们“节省”了计算能力。
他们拥有的文件名是这样的：filename =“ =？Encoding？Type？;并且它的发生是这样的：filename * 0 * = encoding”（STA ?? !!）。第二个是较新的标准RFC5987。该标准明确声明该文件名* 0 * = ENC，文件名=“ =？ 同样的事情。 在这个地方，我终于确信他们在嘲笑我。 我不知道该如何正常处理。
与往常一样，苹果单独得分。 他们通常有自己的某种标准。 展望未来，长时间尝试处理其代码导致了唯一正确的解决方案：“错误：不支持Apple邮件。”
雷鸟做到了。 悲痛的是，我进入了它的源代码，但是在一个半千兆字节的代码中找不到用于python和Java方言混合的必要部分。 在他们的IRC中提供了帮助，他们好心地告诉我在哪里看，但仍然找不到。
但是他并没有灰心。 不要阅读文档@编写代码，您就完成了。 不，认真的说，我必须做些事情来使MIME的结尾更加接近。
批处理脚本还不够。 结果是
在C＃和dotNet中使用了命令行实用程序 。
该实用程序有两种操作模式：
第一：只提取附件。 同时，它可以与Windows的编码一起正常使用。
第二：这里主要的乐趣。 现在，我们仍然可以将邮件附件与邮件分开存储！ 该实用程序
会创建一个新字母，而不是旧字母 ：将
附件切掉，然后将字母重新格式化为采用UTF编码的纯HTML，而不会限制行的长度。 文本/普通部分作为基础。 如果html部分中有表，则它会在保持表内部格式的同时进行传输，但是此功能可以正常使用。 在当前字母文本的末尾（如果是答案或转发），将插入网络资源的链接以及提取文件的路径，格式为文件///和ftp：//。
该系统已经过10000多个字母的测试，并已部署在现有基础架构上。
明确的优势：+为：
后备
它开始于01:00:08
并成功完成了03:26:32
成为：
后备
它开始于01:00:09
并成功完成了01:40:36
+节省了30％以上的存储空间：文件从繁重的Base64等类似文件转换为普通文件系统格式，甚至在单个邮箱中也发现了很多重复项。
+提高了服务器和邮件程序处理邮箱的速度。
+消失“我打开邮局的一封信，对其进行了10个小时的编辑，结果无法生存”
+您可以拒绝配额。
+仍然可以在邮件中找到附件，而不是简单地将其传输到文件存储中。
+即将结束MIME。 pent悔，作者！
决定的缺点：-有些字母（但不是附件）仍然有效。 基本上不是内部的，而是在某些客户中查看时；
-在ftp中，一些恶魔不断地被破坏；
-并非所有电子邮件客户端都支持通过文件打开：///
有争议的问题：？ 不支持Apple Mail。 对我来说，佛陀与他同在。
？ 打败具有复杂格式的字母。 通常这些是来自预订或广告的传单；
？ 如果ftp服务器位于非标准端口上，则可能存在访问问题。 由邮件漫游器决定。
以这样棘手的方式解决了问题。
感谢您的关注！