Procmail error 231

Procmail error 231

am 10.08.2007 11:46:37 von Giles Chamberlin

I'm getting problems with mail being bounced stating that:

(expanded from ): Command died
with status 231: "exec /usr/bin/procmail"

though the message is also succesfully filed in the correct folder.


I'm using fetchmail to collect, .forward to send it to procmail:

"|exec /usr/bin/procmail"

and a .procmailrc:


SHELL=/usr/bin/sh
MAILDIR=${HOME}/Mail
VERBOSE=yes
LOGFILE=${HOME}/Procmail/log
LOGABSTRACT=all

:0:
* ^X-Spam-Flag: YES
$MAILDIR/spam

:0:
* ^Subject:.*SPAM
$MAILDIR/spam

# Accept all the rest to your default mailbox
:0:
$MAILDIR/active




Procmail log file is unexceptional:

procmail: Assigning "LOGABSTRACT=all"
procmail: No match on "^X-Spam-Flag: YES"
procmail: No match on "^Subject:.*SPAM"
procmail: Locking "/home/giles/Mail/active.lock"
procmail: Assigning "LASTFOLDER=/home/giles/Mail/active"
procmail: Opening "/home/giles/Mail/active"
procmail: Acquiring kernel-lock
procmail: Unlocking "/home/giles/Mail/active.lock"
procmail: Notified comsat: "giles@1162241:/home/giles/Mail/active"
> From MAILER-DAEMON Fri Aug 10 08:44:51 2007
Subject: fubar
Folder: /home/giles/Mail/active


All suggestions gratefully received!


--
Giles

Re: Procmail error 231

am 12.08.2007 02:55:20 von Garen Erdoisa

Giles Chamberlin wrote:
> I'm getting problems with mail being bounced stating that:
>
> (expanded from ): Command died
> with status 231: "exec /usr/bin/procmail"

From your comments it seems that there are 3 programs involved here;
"fetchmail", "sendmail" (or some other mail daemon), shell "exec" and
"procmail". It's unclear from your comments which of those commands may
have generated this particular exit status. I doubt the exit status was
caused by procmail in this case, since your dump of the procmail log
doesn't show any error conditions in the log and the mail was in fact
delivered as expected. You would need to do some testing to figure out
which program gave that exit status which may shed some light on what
it's trying to tell you about it. If it's sendmail for instance, the
return codes per RFC 2821 indicate that 231, while non standard, is an
exit status indicating that the mail was accepted. fetchmail hands off
to a local instance of sendmail by default unless specifically told to
use some other means of delivery. Sendmail is what uses the .forward
mechanism, and you can use that to invoke other delivery agents such as
procmail in this case.

>
> though the message is also succesfully filed in the correct folder.
>
>
> I'm using fetchmail to collect, .forward to send it to procmail:
>
> "|exec /usr/bin/procmail"

Suggestion:
Have fetchmail invoke procmail directly as it's mail delivery agent
instead of using the sendmail ".forward" mechanism as an extra step to
do the same thing. (I'm in favor of eliminating redundancy when possible
and in this case there is no need to involve sendmail since the delivery
is to your account on the local machine.)

In your .fetchmailrc put something like:

------ BEGIN ~/.fetchmailrc ------

set syslog
set idfile "/home/localusername/.fetchids"
set postmaster "postmaster"
set invisible

poll mail.example.com with proto pop3 and options no dns
user "remoteusername" there with password "somepassword" is
localusername here and wants mda "/usr/bin/procmail -d localusername"

----- END OF FILE -----

> [SNIP]

--
Garen

Re: Procmail error 231

am 13.08.2007 17:36:31 von Giles Chamberlin

Garen Erdoisa writes:

> Suggestion:
> Have fetchmail invoke procmail directly as it's mail delivery agent
> instead of using the sendmail ".forward" mechanism as an extra step to
> do the same thing.

Interesting I've done that and the problem seems to have gone way
implying that it was an MDA problem. I'm using postfix so I'll dig
through and see why that might issue a 231 error.

Thanks for the help


--
Giles