Re: pattern options "w"

> > 
> >   Looking at an  older .mailfilter file I see a pattern with a ":w" option.  
>I don't see  this in the manual page
> > at  http://www.courier-mta.org/maildrop/maildropfilter.html but maybe it's an  
>allowable PCRE option? 
>
> > Does it do the same as ":hb"???
> 
> The 'w'  option was deprecated when maildrop switched from its own regexp 
>parser to PCRE.  This option
> was exactly the same as :hb. This option treated the entire header,  or body, 
>or both, as selected by :h
> and :b, as a single string, instead of  searching each individual line of a 
>message, so your search pattern
> could  include newline characters.

Thank you.  I do now see there is a minor reference to it being removed with the 
change from 1.x to 2.x.  Thanks for the more detailed explanation.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

maildroprc - bypass the .mailfilter file to limit spam scan size

Is it possible to bypass the .mailfilter in the user's folder with code in
the maildroprc file? I would like to limit the size of files scanned with
spamassasin but can not control what users do in their .mailfilter file.

maildroprc logic would go like this:
If SIZE if < 250000
 Use the users.mailfilter file
Else
 Bypass the users.mailfilter file
END
--

-- 
View this message in context: http://old.nabble.com/maildroprc---bypass-the-.mailfilter-file-to-limit-spam-scan-size-tp29634526p29634526.html
Sent from the courier-maildrop mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev

Re: maildroprc - bypass the .mailfilter file to limit spam scan size

COGZ writes:

> 
> Is it possible to bypass the .mailfilter in the user's folder with code in
> the maildroprc file? I would like to limit the size of files scanned with
> spamassasin but can not control what users do in their .mailfilter file.
> 
> maildroprc logic would go like this:
> If SIZE if < 250000
>  Use the users.mailfilter file
> Else
>  Bypass the users.mailfilter file
> END

Executing an exit or a to statement in the global maildroprc file will 
terminate mail filtering.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
Courier-maildrop mailing list
Courier-maildrop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/courier-maildrop

Re: maildroprc - bypass the .mailfilter file to limit spam scan size

Thanks for the info. When I do that it looks like it prevents deliver of the
message also.

if ($SIZE > 50000) 
{ 
  exit
} 

Sam Varshavchik wrote:
> 
> COGZ writes:
> 
>> 
>> Is it possible to bypass the .mailfilter in the user's folder with code
>> in
>> the maildroprc file? I would like to limit the size of files scanned with
>> spamassasin but can not control what users do in their .mailfilter file.
>> 
>> maildroprc logic would go like this:
>> If SIZE if < 250000
>>  Use the users.mailfilter file
>> Else
>>  Bypass the users.mailfilter file
>> END
> 
> Executing an exit or a to statement in the global maildroprc file will 
> terminate mail filtering.
> 
> 

Re: maildroprc - bypass the .mailfilter file to limit spam scan size

COGZ writes:

> 
> Thanks for the info. When I do that it looks like it prevents deliver of the
> message also.
> 
> if ($SIZE > 50000) 
> { 
>   exit
> } 

That's what you wanted to do: to stop mail filtering.

If you want to take the default action of delivering to the default mailbox, 
use to $DEFAULT instead of exit.

> 
> 
> Sam Varshavchik wrote:
>> 
>> COGZ writes:
>> 
>>> 
>>> Is it possible to bypass the .mailfilter in the user's folder with code
>>> in
>>> the maildroprc file? I would like to limit the size of files scanned with
>>> spamassasin but can not control what users do in their .mailfilter file.
>>> 
>>> maildroprc logic would go like this:
>>> If SIZE if < 250000

Re: maildroprc - bypass the .mailfilter file to limit spam scan size

Works great, thanks!

if ($SIZE > 200000) 
{ 
 to $DEFAULT 
} 

Sam Varshavchik wrote:
> 
> COGZ writes:
> 
>> 
>> Thanks for the info. When I do that it looks like it prevents deliver of
>> the
>> message also.
>> 
>> if ($SIZE > 50000) 
>> { 
>>   exit
>> } 
> 
> That's what you wanted to do: to stop mail filtering.
> 
> If you want to take the default action of delivering to the default
> mailbox, 
> use to $DEFAULT instead of exit.
> 
>> 
>> 

Opening Bracket Syntax

Hello,

  Am I going out of my mind or is it ONLY required to keep the opening curly 
bracket on the SAME line as the test for the EXCEPTION keyword?  For example, 
this works:

exception {
   if (/^From:.*fred/:h)
   {
      to "$DEFAULT/.test/"
   }
}

  But this gives a .mailfilter syntax error:

exception
{
   if (/^From:.*fred/:h)
   {
      to "$DEFAULT/.test/"
   }
}

  Is there a reason for this or is it an oversight or am I missing something 
else?

Thank you!

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances

Re: Opening Bracket Syntax

email builder writes:

> Hello,
> 
>   Am I going out of my mind or is it ONLY required to keep the opening curly 
> bracket on the SAME line as the test for the EXCEPTION keyword?  For example, 
> this works:
> 
> exception {
>    if (/^From:.*fred/:h)
>    {
>       to "$DEFAULT/.test/"
>    }
> }
> 
>   But this gives a .mailfilter syntax error:
> 
> exception
> {
>    if (/^From:.*fred/:h)
>    {
>       to "$DEFAULT/.test/"
>    }
> }
> 
>   Is there a reason for this or is it an oversight or am I missing something 
> else?

Correct. This is the syntax. Maildrop's syntax parser treats newline as 
syntactically equivalent to semicolons, that separate statement sequences.

Re: pattern options "w"

> >  Looking at an  older .mailfilter file I see a pattern with a ":w" option.  I 
>don't see  this in the manual
> > page at  http://www.courier-mta.org/maildrop/maildropfilter.html but maybe 
>it's an  allowable
> > PCRE option?  Does it do the same as ":hb"???

> 
> The 'w'  option was deprecated when maildrop switched from its own regexp 
>parser to PCRE.
>This option was exactly the same as :hb. This option treated the entire header,  
>or body, or
> both, as selected by :h and :b, as a single string, instead of  searching each 
>individual line of a
> message, so your search pattern could  include newline characters.

So is there a way now to test against the whole body string?  Specifically so 
that ^ and $ only match at the beginning and end of the body?  It also doesn't 
appear the PCRE pattern modifiers are allowed (.mailfilter(18): Missing), so a 
modifier like /s wouldn't be possible (although that still wouldn't solve the 
main question)

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: pattern options "w"

email builder writes:

> 
> 
>> >  Looking at an  older .mailfilter file I see a pattern with a ":w" option.  I 
>>don't see  this in the manual
>> > page at  http://www.courier-mta.org/maildrop/maildropfilter.html but maybe 
>>it's an  allowable
>> > PCRE option?  Does it do the same as ":hb"???
> 
>> 
>> The 'w'  option was deprecated when maildrop switched from its own regexp 
>>parser to PCRE.
>>This option was exactly the same as :hb. This option treated the entire header,  
>>or body, or
>> both, as selected by :h and :b, as a single string, instead of  searching each 
>>individual line of a
>> message, so your search pattern could  include newline characters.
> 
> So is there a way now to test against the whole body string?  Specifically so 

No, it's a limitation of the PCRE library, which requires the entire search 
text to be in a memory buffer. maildrop is not going to load a 10mb message 
into memory.

> that ^ and $ only match at the beginning and end of the body?  It also doesn't 
> appear the PCRE pattern modifiers are allowed (.mailfilter(18): Missing), so a 
> modifier like /s wouldn't be possible (although that still wouldn't solve the 
> main question)