附件的 ripmime 权限答案

【问题标题】：ripmime permissions for attachments附件的 ripmime 权限
【发布时间】：2012-06-11 15:17:03
【问题描述】：

我们使用 ripmime 和 Procmail 将电子邮件内容提取到文件中。提取电子邮件正文（文本）时，ripmime 正确使用配置的 procmail UMASK (022) 文件，但是当有附件时，它会为带有 077 umask 的附件创建文件。以下是 ripmime 为一封带有“testTrades2.csv”附件的电子邮件创建的文件示例：

-rw-r--r--  1 fsdevprod   fsdevprod     2341 2012-06-07 06:36 textfile4
-rw-r--r--  1 fsdevprod   fsdevprod       19 2012-06-07 06:36 textfile3
-rw-r--r--  1 fsdevprod   fsdevprod      294 2012-06-07 06:36 textfile2
-rw-r--r--  1 fsdevprod   fsdevprod      573 2012-06-07 06:36 textfile1
-rw-r--r--  1 fsdevprod   fsdevprod        0 2012-06-07 06:36 textfile0
-rw-------  1 fsdevprod   fsdevprod       66 2012-06-07 06:36 testTrades2.csv

以下是 procmail rc 文件中调用 ripmime 的方式：

| ripmime -i - -d /tmp

为什么“testTrades2.csv”与 textfile* 文件有不同的权限，有什么办法让它使用相同的 UMASK？

我们正在使用 ripmime v1.4.0.9。

谢谢，大卫

【问题讨论】：

它是不是一个 uuencoded blob 而不是一个正确的 MIME 附件？ uuencode 具有在 begin 行中编码的预期权限。

标签： file-permissions procmail umask

【解决方案1】：

ripmime 源 (mime.c) 有很多这样的：

open(fullpath, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);

所以它是硬编码的。我把它们改成这样：

open(fullpath, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);

并重新编译。现在这些文件被创建成组并且公开可读。不是一个理想的解决方案，因为它也是硬编码的，但它对我有用。

理想情况下，它应该是命令行可配置的，这不难做到，然后发送给 ripmime 维护者。

【讨论】：

硬编码放松很好，因为用户可以根据需要设置更严格的umask。

【解决方案2】：

:0:
* ^From.*xxx@xxx.ru

{

:0 c:
| ripmime -i - --no-nameless -d $MAILDIR/xxx

:0:
| chmod 777 $MAILDIR/xxx/*

}

【讨论】：

-1 代表chmod 777。使用 sane mode 值，这作为一种粗略的解决方法是可以接受的，尽管单个操作会更优雅。