Michael Ghens <mghens(_at_)picard(_dot_)sbcc(_dot_)cc(_dot_)ca(_dot_)us> writes:
You might want to try this one. I works for me. The subject line Bounce
this is for testing.
:
^(Subject.*Bounce this|From(_dot_)*luser(_at_)anyware(_dot_)com)
{
LOG="Your mail is no longer accepted at this address"
EXITCODE=69
HOST=done
}
If writing a new recipe, I'd suggest using the new style with ":0" and "*"s:
:0
* ^(X-Bounce-test:|From(_dot_)*luser(_at_)anyware(_dot_)com)
....
Makes it not as easy to make a make mistake later.
Also, the LOG=... won't go to sendmail (where it will be included in
the bounce message) if you've done a LOGFILE=... earlier. I'd
therefore suggest changing the action to something like:
....
{
# EX_UNAVAILABLE = 69
EXITCODE=69
:0 ih
|echo "Mail refused by destination address"
}
...unless you're a fanatic keen to save a process, in which case the
following should also work on newer OSs with /dev/fd:
{
# EX_UNAVAILABLE = 69
EXITCODE = 69
LOGFILE = /dev/fd/1
LOG = "Mail refused by destination address"
HOST = done
}
...which brings us back to the original (almost).
(Opening /dev/fd/# is equivalent to dup'ing the # file descriptor, so
the LOGFILE=/dev/fd/1 directive above has procmail set the logfile to
be the same as stdout. That in turn should still be a path back to
sendmail, as sendmail sets stdout and stderr to be the same when it
starts mailers.)
Depending on the circumstances I'd be tempted to set EXITCODE to
67 (EX_NOUSER), if you wanted it to appear that your account was
renamed or gone.
Philip Guenther