Re: Interaction of reformail -D with EX_TEMPFAIL

[Resending with minor modifications as I used the wrong From address]

On Tue, Mar 10, 2026 at 08:13:32PM -0400, Sam Varshavchik wrote:
> Julian Gilbey writes:
> 
> > I'm not sure where the error messages (to stdout) are meant to be
> > logged by exim, but they seem to vanish into the ether...  But here's
> > what strace has to say (and it gave an error on the very first test
> > message I tried; this may or may not be the cause of the other errors
> > I've observed):
> > 
> > newfstatat(AT_FDCWD, "/var/mail/jdg/tmp", 0x7ffc77e06440, 0) = -1
> > ENOTDIR (Not a
> >  directory)
> [...]
> > openat(AT_FDCWD, "/var/mail/1731543.0.erdos", O_WRONLY|O_CREAT, 0644) =
> > -1 EACCES (Permission denied)
> 
> And, maildrop cannot create a lock file. I take it, it was not your intent
> to request maildrop to deliver your mail to /var/mail/jdg.
> 
> There was nothing in your .mailfilter that you showed that referenced this
> mbox file.

Hi Sam,

Thanks for the analysis!

I didn't show the whole of my .mailfilter file (it's mostly quite
boring), but it finishes with the line:

to $DEFAULT

as it is my (explicit) intention to save any messages that don't get
redirected to somewhere else to the default mailbox.  And strangely,
it seems that it usually works (I do get lots of mail saved into
/var/mail/jdg), but occasionally it fails.  However, when using the
strace wrapper, it consistently tries to create a dot-lock file and
then fails.  Also, exim drops any output from temporarily failed pipe
routers, so the error messages from maildrop are lost.

So I'm now using a wrapper around maildrop instead to diagnose the
issue:

#!/bin/bash

LOGFILE=/var/tmp/maildrop.trace
date >> $LOGFILE
/usr/bin/maildrop "$@" &>> $LOGFILE
status=$?
echo "maildrop exited with status $status" >> $LOGFILE
exit $status

So far, only two invocations of maildrop have failed with the
unhelpful message:

/usr/bin/maildrop: Internal error.

In both cases, the message failed before it got to either the
reformail line or the "to $DEFAULT" line - there is no log message at
all in the log file.  (My .mailfilter specifies a logfile, and then
writes a brief log message before doing anything else.)  Both these
messages were delivered without problem on the second attempt.

I'll continue waiting, and if anything more interesting ensues, I'll
report back....  Nothing has failed at the "to $DEFAULT" line yet.

Best wishes,

   Julian