I did an update yesterday evening, and didn't spot that it had changed permissions on my .procmailrc. Consequently no mail came in after that. I've been out most of today, so just got it fixed, but what will have happened to the mail for the missing period? Maillog just shows that messages have been passed to procmail. Procmail won't run if the perms are wrong, so where do the messages go?
Anne
Anne Wilson wrote:
I did an update yesterday evening, and didn't spot that it had changed permissions on my .procmailrc. Consequently no mail came in after that. I've been out most of today, so just got it fixed, but what will have happened to the mail for the missing period? Maillog just shows that messages have been passed to procmail. Procmail won't run if the perms are wrong, so where do the messages go?
$HOME/dead.letter ?
nate
On Mon, Jun 30, 2008 at 12:08:03PM -0700, nate wrote:
Anne Wilson wrote:
I did an update yesterday evening, and didn't spot that it had changed permissions on my .procmailrc. Consequently no mail came in after that. I've been out most of today, so just got it fixed, but what will have happened to the mail for the missing period? Maillog just shows that messages have been passed to procmail. Procmail won't run if the perms are wrong, so where do the messages go?
$HOME/dead.letter ?
A _sane_ delivery agent would definately return a temporary error (4xx) either to it's own internal queue, or return the error to the connecting MTA. The mail would in that case survive for a queueing period which is usually 5 to 7 days.
But, when it comes to procmail, it might depend on your invocation:
PROCMAIL(1) On general failure procmail will return EX_CANTCREAT, unless option -t is specified, in which case it will return EX_TEMPFAIL.
Are you using sendmail or some other mda?
Investigating sendmail source you'll find:
./sendmail/sysexits.h: * EX_CANTCREAT -- A (user specified) output file cannot be * created.
* EX_TEMPFAIL -- temporary failure, indicating something that * is not really an error. In sendmail, this means * that a mailer (e.g.) could not create a connection, * and the request should be reattempted later.
./sendmail/deliver.c:
case EX_NOINPUT: case EX_CANTCREAT: case EX_NOPERM: status = "5.3.0"; break;
Unfortunately, for you, if -t was left out, it would mean a 5xx error code - permanent error - and a /dev/null of your email.
-- Mikael