On 14 Aug, Udi Mottelo wrote:
| On Wed, 14 Aug 2002, Don Hammond wrote:
|
| [...]
|
| > :0b:uue.lock
|
| You can lock object, but, you can not lock action!
| It must be:
|
| :0 bw
|
| > * ^From:(_dot_)*subscribe(_at_)drweb(_dot_)ru
| > * B ?? ^begin [0-7][0-7][0-7] \/.*
|
| BH are the default flags.
|
| > * B ?? ^end$
| > * 1^3 B ?? ^M
| > |uudecode >"/path/to/final/destination/$MATCH"
|
| uudecode has no output. The third field in uucode header is
| the name of the file that the uudecode must create (it is well
| known security hole in old sendmail that have the alias
| uucode: uudecode. You could send a uucode message with header:
| begin 777 /etc/passwd)
| btw, the second field is the permission that supposed to set by
| uudecode.
You *can* use a lock file where I showed it. What you can't use is an
implicit lockfile, which is why I named it. I stand by that part of the
recipe. "H" is the default flag, not BH, at least in my version (and I
suspect all versions) of procmail. I could've used "BH" at the top of
the recipe, but this is just the way I'm accustomed to writing recipes
that scan both headers and body, but not necessarily for each
condition. I stand by the conditions in the recipe.
Which brings is to the action line. You are correct that uudecode has no
stdout. My bad. Change the action line to:
|uudecode -o "/path/to/final/destination/$MATCH"
As for the rest. I know. If the filename and permissions fields are of
concern to the OP, he can ask for, or write his own conditions to
suitably and safely munge them. There was no indication this was an
issue.
--
Reply to list please, or append "8" to "procmail" in address if you must.
Spammers' unrelenting address harvesting forces me to this...reluctantly.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail