procmail
[Top] [All Lists]

Re: Returning temporary failures

1997-10-25 16:52:28
| Replies again directed to list.

OK ...

When I suggested some code involving lockfile to Aaron Schrab, he replied,

| While most of these users do not have a .procmailrc, there are also
| many that just use it to send spam to /dev/null, but still have
| everything else delivered to $DEFAULT. The number of users that do
| this is likely to increase.

Then my suggestion won't help that case, as we both know.  Anyhow, I
proposed this:

| >   :0
| >   * ! ? test -r $HOME/.procmailrc
| >   * ! ? lockfile -r $NUMBER_OF_RETRIES -ml
| >   {
| >    # Do whatever it takes to requeue a message on your system:
| >    EXITCODE=75
| >    HOST 
| >    # Since the lockfile was never created, it needn't be removed.
| >   }

And Aaron asked,

| Wouldn't it then lock up when it actually tries to deliver?

Good point; running lockfile doesn't make the lockfile's name known to
procmail the way that setting the LOCKFILE variable does.  Let's fix that.

    :0
    * ! ? test -s $HOME/.procmailrc
    {
     :0
     * ! ? lockfile -r $NUMBER_OF_RETRIES -ml
     {
     # Do whatever it takes to requeue a message on your system:
      EXITCODE=75
      HOST 
     # Since the existing lockfile belongs to a different process, we
     # should not remove it.
     }

     :0Ec # while we have the lock, use it
     $ORGMAIL

     :0ahi # no w or W!
     | lockfile -mu
    }

Procmail has dedicated variables like LOCKSLEEP and LOCKTIMEOUT to
simulate lockfile's other options besides -r; if it had one for this
(would NORESRETRY work?) we could do something much saner, like just
setting that variable in /etc/procmailrc (though a cunning user could
change its value in .procmailrc).

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