procmail
[Top] [All Lists]

Re: LASTFOLDER blues

2007-03-25 11:23:44
On Sun, Mar 25, 2007 at 07:24:14PM +0200, Dallman Ross wrote:
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:

What if your delivery actions differ? Some of the mails get processed
into a notofy inbox folder, other forwarded.
 
   :0
   * conditions for delivery to A
   { MYDELIVERY = "${MYDELIVERY+$MYDELIVERY }FolderA/" }

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

   :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?

Beacuse an MDA's rule #1 is to not lose mail under any
circumstances. As an exageration to illustrate the situation: Why
doesn't procmail nod off the calling process right from the start to
speed up processing then, if we don't want procmail to be liable at
all for lost mails?

It's really the top-most rule.

That seems to me to be up to you to figure out and
deal with separately.

No, not really.

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.

This argument is not very convincing. Everything falls under the
admin's responsibility for one, and concerning procmail: If a fatal
error is found it does bounce back the mail, so why can't this be done
in this case, too?

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 }

Sigh --- this solution is clear, I just don't want to double all my
recipes with more bloat :/

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

That's a joke, right? The subject is called "LASTFOLDER blues" because
LASTFOLDER cannot be used for that query ...
-- 
Axel.Thimm at ATrpms.net

Attachment: pgp4kP8KsROG0.pgp
Description: PGP signature

____________________________________________________________
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>