procmail
[Top] [All Lists]

Re: LASTFOLDER blues

2007-03-25 10:35:54
On Sat, Mar 24, 2007 at 11:34:15PM +0100, Axel Thimm wrote:

On Sat, Mar 24, 2007 at 01:49:49PM -0700, Bart Schaefer wrote:

It seems to me you're bringing this on yourself.

Well, check the specification of the problem and if you can find a
better solution I'm all ears.

There's a reason for the first-delivery-stop design; if the delivery
fails, processing doesn't stop, so $DEFAULT is always a failsafe.
It's your algorithm that's "fragile": the mail isn't "lost" until
you explicitly throw it away by assigning to HOST.

Because that's the only way to have multiple deliveries of one mail
done.

That "only way" stuff always seems specious to me when it comes
to computers. :-)  Here's another way.  I can think of others, too:

   :0
   * conditions for delivery to A
   { MYDELIVERY = "${MYDELIVERY+$MYDELIVERY }FolderA/" }

   :0
   * conditions for delivery to B
   { MYDELIVERY = "${MYDELIVERY+$MYDELIVERY }FolderB/" }

   :0
   * conditions for delivery to C
   { MYDELIVERY = "${MYDELIVERY+$MYDELIVERY }FolderC/" }


   :0
   * MYDELIVERY ?? .
   {
      :0
      $MYDELIVERY

      :0 e
      { ERRORCODE = 77 }
   }


It turns out that the e-flag won't run unless there was not
any delivery to any of the possible Maildir folders despite
the existence of $MYDELIVERY.


I surmise that you're using :0c: followed later by setting HOST
because you want to deliver the mail to more than one non-$DEFAULT
mailbox, but never both to any other mailboxes and also to $DEFAULT.

The issue was outlined in my first post - it's rather simple: I want
to have multiple deliveries of the same mail with different
conditions. And I want to not lose mail.

But anyway, Bart is right: if you're having filesystem troubles,
why does procmail have to become bloatware to be able to figure
that out?  That seems to me to be up to you to figure out and
deal with separately.  If that requires a separate (e-flag)
recipe, well, so be it.  What if your fallback mail folder also
becomes unwriteable?  Is that also procmail's responsibility?
At some point the responsibility shifts to the operator/sysadmin.
The only debate is where that point exactly falls.


If LASTFOLDER were left unset on failed deliveries, then one could not
make use of its value in the :0e recipies that you're unhappy about
needing.

Why would I need it there? Since every (masked) delivery action seems
to need to be paired by :0e counterparts I know where the mail was
heading to. And the sanest thing to do when such a failure comes up is
to set EXITCODE and have the mail bounce back, since it is really for
the catastrophy scenario (disk bad or full, over quota etc).

    :0 e
    { EXITCODE = 77 }



One possible approach to fix your problem without completely rewriting
your recipies is to replace
{ HOST=stop }
with
{ DEFAULT=/path/to/safe/backup/location
  SWITCHRC }

(why would I need SWITCHRC? This is the last recipe)

Have DEFAULT be /dev/null unless we have the error condition
(as determined via the e-flag recipe); othrewise, have it
be $FALLBACK.

For one if the disk is bad or some other catastrophy has happened I
don't have /path/to/safe/backup/location. Instead I want procmail to
error out.

    :0 e
    { EXITCODE = 77 }



and then periodically [automatically, e.g. daily with logrotate] clean
out the backup location.  Then if you run into a problem where a
message got delivered nowhere else, you can go retrieve it from the
backup.

And how do I know that the message was not delivered elsewhere? ;)

  :0 e
  * LASTFOLDER ?? .
  $FALLBACK


Dallman

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

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