6.0.0-beta1
7/11/25

[#5581] procmail expression problem
Summary procmail expression problem
Queue Ingo
Queue Version 1.1.2
Type Bug
State Resolved
Priority 2. Medium
Owners selsky (at) columbia (dot) edu
Requester zmoelnig (at) iem (dot) at
Created 07/25/2007 (6561 days ago)
Due 07/25/2007 (6561 days ago)
Updated 12/29/2007 (6404 days ago)
Assigned 09/05/2007 (6519 days ago)
Resolved 12/29/2007 (6404 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
12/29/2007 05:13:01 AM Chuck Hagenbuch Comment #13
State ⇒ Resolved
Reply to this comment
I agree - changes are merged. Thanks!
12/29/2007 12:37:06 AM selsky (at) columbia (dot) edu Comment #12 Reply to this comment
You could probably create them (using UTF-7 if necessary, maybe).
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.
12/28/2007 11:41:48 PM Chuck Hagenbuch Comment #11 Reply to this comment
You could probably create them (using UTF-7 if necessary, maybe).
12/28/2007 11:34:16 PM Matt Selsky Comment #10 Reply to this comment
My server  only lets me specify folders that actually exist on IMAP.   
How did the user specify these wacky folders?
12/28/2007 11:29:33 PM Matt Selsky Comment #9 Reply to this comment
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...
12/28/2007 11:01:41 PM Chuck Hagenbuch Comment #8
Priority ⇒ 2. Medium
Reply to this comment
Matt, will you be able to comment on this soon? I'd like to have this 
resolved for Ingo 1.2.0.
11/05/2007 06:06:29 PM Chuck Hagenbuch Comment #7 Reply to this comment
Matt - any word on this?
09/05/2007 02:05:30 PM Jan Schneider Assigned to Matt Selsky
State ⇒ Assigned
 
08/22/2007 03:51:27 AM Chuck Hagenbuch Comment #6 Reply to this comment
There are at least starts of some tests in ingo/lib/tests/.
08/22/2007 03:48:42 AM Matt Selsky Comment #5 Reply to this comment
I'm not sure exactly which test data you're looking for, but this is
Just phpt files that would show the generated scripts for each backend...
08/22/2007 01:24:07 AM Chuck Hagenbuch Comment #4 Reply to this comment
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.
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

}
08/15/2007 05:41:40 AM Matt Selsky Comment #3 Reply to this comment
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?
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.
07/31/2007 09:09:45 PM Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
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?
07/25/2007 02:41:14 PM zmoelnig (at) iem (dot) at Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ procmail expression problem
Due ⇒ 07/25/2007
Queue ⇒ Ingo
State ⇒ Unconfirmed
Reply to this comment
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

Saved Queries