procmail
[Top] [All Lists]

RE: race condition with sendmail

1999-12-07 07:31:30
From: Dallman Ross [mailto:dman]


From guenther(_at_)gac(_dot_)edu  Mon Dec  6 23:11:35 1999

Dallman Ross <dman(_at_)netcom(_dot_)com> writes:
There is a race condition (I guess that's what

Can you include the *entire* bounce message

that.  Well, anyway, here is a header:

Looking at that, I realize that I'm compounding
the problem with a loop.  I have my .procmailrc look for
bounces and send them to my pop spool.  Since it is still
locked, they keep bouncing.

 :0  # dispatch bounces or loops immediately without further processing
 * $ (^FROM_DAEMON|^X-Loop: ${SITES}bot)
 ! xxxxxxx(_at_)pop

I could help here by (a) storing bounces locally; or (b)
adding a wait period somehow between delivery attempts.
Or maybe somehow (c) try delivery X times and then save
locally.

A problem with (a) is that this is not my regular shell
account that I habituate daily, and I don't log in there
that often except to do maintenance on procmail or my
shell account or domain stuff that I don't accomplish
with ftp.  Since there was nothing wrong with the original
message, except that it arrived in a race condition, my
use of (a) under these circumstances would cause me not
to see relevant current mail for some unknown period of
time.

(b) should be easy if one of you tells me how to include
a wait period.  But it doesn't solve the original problem
of why the server's sendmail daemon is bouncing mail
that arrives coincidental to other mail.  I will still
get a bounce wrapper when one shouldn't have been generated;
and furthermore, the later attempt at delivery could also
find itself in a new race condition with other mail.

(c) is probably safest if I can't help the system operator
fix his configuration.  But it still leaves me with the
problems I describe above in both (a) and (b).

Best would be to fix the server so that it doesn't bounce
these messages but queues them internally somehow.  Isn't
that how it's supposed to work?

Appended question: should I still have an escape hatch
for sending bounces to the pop server?  Probably so, I
would imagine, but I would like to solicit ideas for the
best approach.

Regards,
DR

--
Dallman Ross
U.S. Voicemail/FAX: +1 (415) 680-2388
Residence Telephone: +49 (0) 6122 / 98 04 46
Cellular Telephone: +49 (0) 177 / 515 34 69
<dman(_at_)netcom(_dot_)com> ? <dman(_at_)nomotek(_dot_)com> ? 
<dman(_at_)oxon(_dot_)de>

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