procmail
[Top] [All Lists]

Re: mailbounce tool

2001-12-13 22:34:31
Paul had asked,

C> Does the return value from a piped
C> command make its way back to the MTA?

As Dallman said, procmail tries to tell the MTA, but what the MTA does about
it varies.  Postfix and sendmail will listen; Smail doesn't give a hell if a
.forward pipe's exit code is non-zero nor even if it can run the program in
the pipe as long as it can fork a shell to attempt the pipe (put a
nonexistent executable into a pipe in .forward under Smail and all incoming
mail to that user will vanish); qmail lives in its own universe but comes
with an executable called "bouncesaying" that allows the user to fire off an
NDN with a default or custom error message.

Tim Luoma has replied,

L> I don't know the answer, however I do have another datapoint... using
L> EXITCODE reveals the contents of the .forward file.

[Remember, folks, we're talking only about what happens when procmail is
invoked from ~/.forward.   The MTA does not give away the contents of your
.forward on a non-zero exit code if procmail is invoked as the LDA.
However, if as an ordinary user you can't change the LDA and you must start
procmail from ~/.forward, you have to deal with this.]

That, too, is MTA-dependent.  Postfix and sendmail will blab, qmail will not
(for qmail it's better to use bouncesaying than to set a non-zero exit
code), and of course Smail will never notice.  I've found two ways to tweak
.forward to deal with Postfix's and sendmail's loose lips:

[a] In .forward, invoke the procmail binary under a different name -- but it
must be followed by your own logname as its $1 because any invocation of the
procmail binary under a basename whose first eight characters are not
"procmail" automatically implies the -d option.  This forces you to use the
default rcfile (generally $HOME/.procmailrc) and none other [except as
called by INCLUDERC or SWITCHRC assignments inside ~/.procmailrc], makes it
impossible to include variable assignments on the command line [they're
incompatible with the -d option for security reasons], and leaves you no way
to prevent procmail from reading /etc/procmailrc if you don't want it to.
But the bounce caused by a non-zero exitcode puts something like this into
the NDN:

  "| exec /users/yourlogname/removed yourlogname" ... user unknown

[b] In .forward, pipe to a hash-banged procmail rcfile that has its execute
bit on (I'm assuming that OSes that don't do hash-bang are obsolete).  The
downside here is that you can use only one command-line option or
command-line variable assignment at most [and not one of each, just one
total, but variable assignments can always be put into the rcfile instead],
procmail doesn't read /etc/procmailrc if you want it to unless you
specifically INCLUDERC it from the rcfile (and then it does so with no
special privileges), and you can't avoid any bugs that creep in (such as the
one with $HOST) when there is an rcfile named on the command line.  But the
NDN for a non-zero exit code looks like this:

  "|/users/yourlogname/deleted" ... user unknown

Either way, someone who reads the NDN will think that your account is
canceled.

I can think of a third variation: just have

 "|exec /path/to/procmail -a canceled # yourlogname"

as your regular .forward -- use the British two-l spelling ,,cancelled'' if
your ISP's administrators would -- and just ignore $1 in your .procmailrc
(or use it as an indication that procmail was started from your .forward
rather than, say, from a cron job, from a shell prompt, or from having
become the LDA in the meanwhile).  If you deliberately set a non-zero exit
code and the MTA honors it but blares the contents of .forward, you're OK;
it looks as though the admins, not you, set your .forward to one for
canceled accounts.

Here's a fourth, what the heck: since without -m procmail looks for an
rcfile in $HOME and already knows your $HOME at this point,

 "|exec /path/to/procmail .terminatedrc # yourlogname"

also does the job, where ~/.terminatedrc is a link to your .procmailrc.  If
you want procmail to read /etc/procmailrc, though, you'll need to INCLUDERC
it explicitly, and it will be processed with no special privileges.



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>