headers
Noah | 3 Sep 2011 20:01

Command time limit exceeded:, "/usr/bin/procmail"

Hi,

so I am receiving notifications that sometimes incoming mail is bouncing 
due to 'Command time limit exceeded:    "/usr/bin/procmail"'

What is the best way to figure out what is causing this.  I am running 
spamd and also invoking spamc from the .procmailrc .

what is the best method to controlling spam?  using spamd or having a 
local invocation of spamc in each users' homedir .procmailrc ?

here is my procmailrc -  is this file fairly complete or are there other 
options I should be considering?

--- snip ---

PATH=/usr/local/bin:/bin:/usr/bin:$PATH
HOME=/home/≤user>
MAILIN=$HOME/mail
DEFAULT=/var/mail/≤user>
#MAILDIR=$HOME/Mail
#LOGFILE=$MAILDIR/from
LOCKFILE=/var/mail/≤user>.lock
NULL=/dev/null

:0fw: spamassassin.lock
| /usr/bin/spamc

:0
* ^X-Spam-Status: Yes
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael J Wise | 3 Sep 2011 21:18
Favicon

Re: Command time limit exceeded:, "/usr/bin/procmail"


On Sep 3, 2011, at 11:01 AM, Noah wrote:

> I am running spamd and also invoking spamc from the .procmailrc .

Don't.
Invoke that stuff from outside, somehow.

Typically people either use a Policy Daemon, or run the mail thru AmavisD "New".

Aloha,
Michael.
--

-- 
"Please have your Internet License             
 and Usenet Registration handy..."
Permalink | Reply | 2 comments |
headers
Noah | 4 Sep 2011 19:34

Re: Command time limit exceeded:, "/usr/bin/procmail"

On 9/3/11 12:18 PM, Michael J Wise wrote:
>
> On Sep 3, 2011, at 11:01 AM, Noah wrote:
>
>> I am running spamd and also invoking spamc from the .procmailrc .
>
> Don't.
> Invoke that stuff from outside, somehow.

you mean dont invoke from the .procmailrc

>
> Typically people either use a Policy Daemon, or run the mail thru AmavisD "New".
>

I will check this out.  when you mention the Policy daemon - do you have 
an example program here or are you referring to spamd?

Cheers,
Noah

> Aloha,
> Michael.
Permalink | Reply | 1 comment |
headers
Michael J Wise | 4 Sep 2011 22:17
Favicon

Re: Command time limit exceeded:, "/usr/bin/procmail"


On Sep 4, 2011, at 10:34 AM, Noah wrote:

> On 9/3/11 12:18 PM, Michael J Wise wrote:
>> 
>> On Sep 3, 2011, at 11:01 AM, Noah wrote:
>> 
>>> I am running spamd and also invoking spamc from the .procmailrc .
>> 
>> Don't.
>> Invoke that stuff from outside, somehow.
> 
> you mean dont invoke from the .procmailrc
> 
>> Typically people either use a Policy Daemon, or run the mail thru AmavisD "New".
> 
> I will check this out.  when you mention the Policy daemon - do you have an example program here or are you
referring to spamd?

Policy Daemon is a Postfix-ism.
Most modern MTAs will have an equivalent.
The idea is a light-weight process that runs at "Envelope" time to do spam processing.

Aloha,
Michael.
--

-- 
"Please have your Internet License             
 and Usenet Registration handy..."
Permalink | Reply | 0 comments |
headers
Robert Bonomi | 25 Sep 2011 23:09

unexpected procmail recipe behavior


The procmail manpages say that procmail regexes behave "exactly" as egrep ones.

I'm baffled as to why this conditon:
  * ^References:.*[<]\/[^>][^>]*
sets MATCH to the  _first_ Message-ID on the line, and not the _last_ one.

Standard regex definition is that repeat patterns are 'greedy' -- i.e.,
that given multiple matches at the same starting point, the -longest-
match will be chose.

Thus, to my understanding, the sequence '.*[<] should match evrything up to
the -last- "<" on the line.

and, in fact, using a sed(1) substitution "s/^.*[<]([^>][^>]*)[>].*$/\1/"
I do get the desired last tiem.

Can anyone 'explain this thing to me" or (with apolgies to The Weavers)
should this old fool just put his chamberpot on his head, saddle up his
milk cow, and ride away ?  *GRIN*

I've had to re-write 'modern egrep'-compliant regexes many times, to get
the desired behavior out of procmail. But, how to re-write this one, where
there may be a variable number of '<...>' items on the line, has got me
stumped.

Does anybody have a _detailed_ description of exactly how procmail's 
'internel pattern-match' works?  Saying it 'works like egrep(1)' is 
woefully incomplete/inaccurate, given the changes to egrep's behavior 
that have occured over the years.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David W. Tamkin | 26 Sep 2011 00:37
Picon
Favicon

Re: unexpected procmail recipe behavior

Robert Bonomi wrote,

> The procmail manpages say that procmail regexes behave "exactly" as egrep ones.

If you're not extracting substrings with \/ and all you care about is the 
presence or absence of a match, they don't behave the same but they get the 
same results.

But if you are extracting substrings, they don't get the same results, and 
"exactly" isn't accurate.

> I'm baffled as to why this conditon:
>    * ^References:.*[<]\/[^>][^>]*
> sets MATCH to the  _first_ Message-ID on the line, and not the _last_ one.
>
> Standard regex definition is that repeat patterns are 'greedy' -- i.e.,
> that given multiple matches at the same starting point, the -longest-
> match will be chose.

Procmail's regexp matching is stingy in the absence of \/; in the presence 
of \/, it is stingy to the left of \/ and greedy to the right.

> I've had to re-write 'modern egrep'-compliant regexes many times, to get
> the desired behavior out of procmail. But, how to re-write this one, where
> there may be a variable number of '<...>' items on the line, has got me
> stumped.

I can't think of a way to write it in a single condition, but I can in two:

  * ^References:.*(<.*>)?<\/[^>]+>$
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego Lima via LinkedIn | 1 Oct 2011 16:46
Picon
Favicon

Invitation to connect on LinkedIn

LinkedIn

Diego Lima requested to add you as a connection on LinkedIn:

Manu,

I'd like to add you to my professional network on LinkedIn.

 
 View invitation from Diego Lima

 

DID YOU KNOW you can use your LinkedIn profile as your website?

Select a vanity URL and then promote this address on your business cards, email signatures, website, etc.

 

© 2011, LinkedIn Corporation 

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail
Permalink | Reply | 0 comments |

Gmane