I'm trying to receive a bounce mail message when an outgoing message cannot reach smtp external server (due to my local internet connection problems).

I send emails using: mutt (compose) - procmail - esmtp (in place of sendmail) - GMail smtp server

When my connection is down and gmail smtp cannot be reached, I need to be alerted with a bounce mail from my email local system.

Is procmail the right "link in the chain" to set up to obtain this behavior? How configure it for bouncing?



set sendmail="/usr/bin/formail -s /usr/bin/procmail -t -m /home/$myuser/.procmailoutrc"


* ^From.*address@gmail
        | formail -I 'From ' | sendmail -v -t -X "$LOGSENDMAIL"


identity address@gmail
        hostname smtp.gmail.com:587
        username "address@gmail"
        password "*"
        starttls required
        helo "*"
mda='/usr/bin/formail -a "Date: `date -R`" | /usr/bin/procmail -d %T'`

Since I found following error:

"SMTP server problem Temporary failure in name resolution"

written in $LOGFILE and not in $LOGSENDMAIL, I thought procmail was able to manage this returned error and send a "delivery failed" message to my mailbox.

As you can see in my config, mboxes name is the same of the real email address...

  • Not sure about the usefulness of formail -s there -- why don't you simply pipe to procmail?
    – tripleee
    Apr 5, 2016 at 10:15

1 Answer 1


You are redirecting the standard output from sendmail to the log file, but standard error is not redirected, and so ends up in the Procmail log file.

I would imagine that sendmail sets a suitable exit code, and that you can simply generate a local bounce message when it fails if you want to.

This is becoming complex enough that I would create a separate script, although the code could probably somehow be inlined to your .procmailout as well.

t=$(mktemp -t sendout.XXXXXXXXXXXX) || exit
trap 'rm -f "$t"' EXIT
trap 'exit 123' HUP INT TERM
formail -I "From " >"$t"
sendmail -v -t -X "$@" <"$t" && exit

# If we reached here, it's a failure
( printf "To: $USER\nFrom: MAILER_DAEMON\nSubject: Bounce\n\n"
  printf "The following message failed to send.  So sorry.\n\n"
  cat "$t" ) | sendmail -oi -t
exit $rc

You could send this script as sendout somewhere in your PATH (make sure it's in Procmail's PATH, too) and call it like

| sendout "$LOGSENDMAIL"

The normal mode of stock Sendmail in case a message cannot be delivered immediately is to queue the message and report a temporary failure after a few hours, then retry until around a week has passed, then return the message as undeliverable if it still could not be delivered. I'm not familiar with esmtp but it sounds to me like maybe the default behavior of Sendmail (and thus in some configurations Postfix, Exim, etc) would perhaps be to your liking, so maybe simply switch to one of those (if esmtp can't be configured to behave similarly) and avoid creating your own solution.

  • It doesn't work properly from within procmail. The script is regularly executed but when it recall sendmail in case of not working network, an other error appears:*** glibc detected *** sendmail: malloc(): memory corruption: 0x09fa8100 ***. It's very strange. I tried to make an other script including just your last part, the one after "# If we reached", and when I launch it directly a mail is regularly delivered in my user mbox. Moreover, when my network is ok your script works fine also from within procmailoutrc and my messages are sent as usual to recipients. Where could be the issue?
    – Joe
    Apr 5, 2016 at 14:44
  • Sounds like a bug in your sendmail (the one from esmtp I'm guessing?) but that alone is not very satisfactory. Maybe there's a bug in my script as well. What's the path to sendmail in these instances; is it the same binary when it fails and when it succeeds?
    – tripleee
    Apr 5, 2016 at 17:24
  • Oh, maybe your sendmail doesn't like the -oi option I habitually passed in?
    – tripleee
    Apr 5, 2016 at 17:25
  • Yes, it is the same script that calls "/usr/bin/sendmail". I tried to remove option "-oi", even if esmtp just ignore it (i read that from man pages). I thought to a bug too... but the same command works fine in the same script if i launch a very similar script containing the same command by hand. The issue appears just when the script is called by procmail. I could try to add headers to a new temp file and finally launch sendmail like the first time sendmail -v -t -X "$@" <"$tempfile2"... perhaps procmail doesn't like the pipe... I can't figure nothing better... :)
    – Joe
    Apr 5, 2016 at 18:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .