Program failure (65) of "usr/lib/cyrus/bin/deliver.
For example, in the end of the logging sequence it shows
Subject : whatever
Folder: /usr/lib/cyrus/bin/deliver -a pwhrmsn -m user.pwhrmsn 2915
as if the mails are delivered correctly.
But there are no mails in the folders.
They're gone to Nirwana.
Is there anybody outside familiar with this problem ?
0) from sysexits.h
#v+
#define EX_DATAERR 65 /* data format error */
#v-
1) Have you tried to remove "From " header (not "From:") from message
passed to cyrus-deliver? AFAIR cyrus does not like it.
#v+
:0
|formail "-IXFrom " |/usr/lib/cyrus/bin/deliver -a pwhrmsn -m user.pwhrmsn
#v-
2) Have you used w (wait for exit) flag in the procmail recipe?
It should give you an option to e.g.
* use maildir as fallback destination
* pass softfail (75) exit code to sendmail if your procmail is
executed by sendmail
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
It is the theory which decides what can be observed.
-- Albert Einstein
> 0) from sysexits.h
> #v+
> #define EX_DATAERR 65 /* data format error */
> #v-
Ah, now I know the reason for "65". Thank You !
> 1) Have you tried to remove "From " header (not "From:") from message
> passed to cyrus-deliver? AFAIR cyrus does not like it.
>
> #v+
> :0
> |formail "-IXFrom " |/usr/lib/cyrus/bin/deliver -a pwhrmsn -m
> |user.pwhrmsn
> #v-
Yes !
The following recipe is for years the first in my included user procmailrcs
:0hfw
|/usr/bin/formail -I "From"
This indeed causes the trouble with procmail.
I changed -I to -X, and now there is no program failure shown in
procmail.log. But the problem still keeps on existing. The mail seems to be
delivered correctly to the users mailboxes. However - there is no new mail
in the /var/spool/imap/user/*user* directory.
> 2) Have you used w (wait for exit) flag in the procmail recipe?
> It should give you an option to e.g.
> * use maildir as fallback destination
> * pass softfail (75) exit code to sendmail if your procmail is
> executed by sendmail
I didn't change any config files in this mail environment for years, so
I suppose a bug in cyrus-imapd 2.3.14-8.3 to be responsible for this.