I agree - changes are merged. Thanks!

I just disabled the IMP listFolders registry call to test.



I committed a fix which generates the following code.



   7: ##### Try to use pipe in folder name #####

   8: :0

   9: * ^From:.*hisemailaddres@example\.com

  10: {

  11:   :0

  12:   * ^Subject: .*exec_command\/.*$

  13:   \|formail\ -rA\ "X-Loop:hisemailaddres@example.com"\ \|\ \(\ cat\ -\ \;

  14: \

  15: myCmd="\$MATCH"\;\ echo\ "Executing:\ \$myCmd"\ \;\ bash\ -c\ "\$myCmd"

  16: \

  17: \)

  18: \

  19: \|\ \$SENDMAIL\ -oi\ -t

  20: }

  21:

  22: ##### Regex Test #####

  23: :0

  24: * ^X-Spam-Score:.*\+\+\+\+\+

  25: {

  26:   :0

  27:   * ^X-Spam-Level:.*\*\*\*\*\*\*

  28:   $DEFAULT

  29: }



I think we can close this ticket.

You could probably create them (using UTF-7 if necessary, maybe).

My server  only lets me specify folders that actually exist on IMAP.   
How did the user specify these wacky folders?

I created 2 rules:



X-Spam-Score contains "*****" and

X-Spam-Score contains "+++++"



which generates:



  7: ##### Spam #####

   8: :0

   9: * ^X-Spam-Score:.*\*\*\*\*\*

  10: $DEFAULT

  11:

  12: ##### Spam 2 #####

  13: :0

  14: * ^X-Spam-Score:.*+++++

  15: $DEFAULT



So, we are not currently quoting correctly.  Looking more...

Matt, will you be able to comment on this soon? I'd like to have this 
resolved for Ingo 1.2.0.

Matt - any word on this?

There are at least starts of some tests in ingo/lib/tests/.

Just phpt files that would show the generated scripts for each backend...

I'm not sure exactly which test data you're looking for, but this is 
the exploit example that caused us to start using escapeshellcmd:



The Foldername

|formail    -rA     "X-Loop:hisemailaddres@excample.com"   |       (   
     cat     -       ;myCmd="$MATCH";  echo    "Executing:     $myCmd" 
;       bash    -c      "$myCmd"

)       |$SENDMAIL        -oi     -t



would result in a prcmail like the following



* ^From:.*hisemailaddres@excample\.com

{

   :0

   * ^Subject:.*exec_command\/.*$

   |formail    -rA     "X-Loop:hisemailaddres@excample.com"   |       
(       cat     -

    ;

         myCmd="$MATCH"; echo    "Executing:     $myCmd" ;       bash   
   -c      "$myCmd"

       )

         |       $SENDMAIL       -oi     -t

}

Seems reasonable.  Do we have any test files?  It would be super easy 
to verify the results then and/or show them to my local procmail expert.

It did used to work before a possibly slightly wrong fix was made for 
a pipe-execution problem (bug 4513). It looks to me like we're using 
escapeshellcmd in too many places now; I am not a procmail wiz but I 
don't see a way to use a pipe to execute a command in any of the 
addCondition() function checks. I think those should go back to being 
quotemeta(). Anyone see anything wrong with that?

ingo generates wrong procmail filter rules with special characters for me.

for instance, i want to create a filter rule that checks whether a 
header-field (X-Spam-Score) has at least 5 "+".

therefore i create a rule where the header field "contains" the 
expression "+++++"

ingo renders this into a procmailrc file like that:

  * ^X-Spam-Score:.*+++++



obviously this is wrong, as the "+" is a special character in regular 
expressions and has therefore to be escaped to something like:

  * ^X-Spam-Score:.*\+\+\+\+\+



of course there is the possibility to use "regular expressions" 
directly, but for ordinary users, i would expect the "contains" 
matching to be ordinary non-regex syntax.



just in case this is a distribution problem: i am using debian/etch 
with ingo1_1.1.2-1





i am pretty sure that this _used_ to work in older versions (i had it 
running on i debian/sarge with the ingo version 1.0.1-1sarge1).



the problem is that my users have created  their spam-filtering rules 
a while ago, and when they now update their filter-rules (e.g. adding 
vacation notes), suddenly a lot of their emails vanish into their 
spam-folders...





yours,

IOhannes