附件的ripmime權限

我們使用ripmime和Procmail將電子郵件內容提取到文件中。提取電子郵件正文（正文）時，ripmime正確使用配置的procmail UMASK（022）作爲文件，但是當存在附件時，它會使用077 umask創建附件文件。下面是ripmime對於有「testTrades2.csv」附件一個郵件創建的文件的一個例子：附件的ripmime權限

-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

這裏的ripmime是如何被稱爲在procmail的RC文件：

| ripmime -i - -d /tmp

爲什麼會出現「testTrades2.csv」與textfile *文件有不同的權限，並且有什麼方法讓它使用相同的UMASK？

我們在ripmime v1.4.0.9。

感謝，大衛

來源

2012-06-07 DavidK

是否有任何機會使用uuencoded blob而不是正確的MIME附件？ 'uuencode'具有編碼在'begin'行中的預期權限。 'chmod 777'的 – tripleee

-1

:0: 
* ^From.*[email protected] 

{ 

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

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

}

來源

2012-07-05 17:12:16 powershot

-1。有了一個理智的模式價值，這將是一個粗略的解決方法，儘管一個動作會更優雅。 – tripleee

的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維護者。

來源

2012-08-15 13:34:53 DavidK

Hardcoded放鬆很好，因爲用戶可以設置一個更緊密的'umask'，如果他們想。 – tripleee

附件的ripmime權限

回答

相關問題