In the interest of getting it into a search engine for others to find, here is
what was happening.
I had a procmail script that would look for certain things, and throw them in
certain folders if the tests passed. I tested this, and thought that it
worked. But I never let a message fall all the way through.
The script as it was running with sendmail before, used to just fail through,
and then tack it onto the users inbox in /var.
Exim didn't do that. Instead it got to the bottom and said "Now What?" Which
technically I think is more correct than before. I mean I said it was going
to a script, so that script should handle it. In any case, I added a catch
all at the bottom of the procmail script to throw it into the users home
directory.
Just like the documentation, once you fix it, force one through, it will
remove it from the retry database, and all the others will get tried again.
Pretty slick when I know how it works!
Thanks for not flaming me!
--Brett
On Wednesday 18 December 2002 13:06, Brett Thorson wrote:
> Ok, well I ran exinext "|/usr/bin/procmail" which I think just returned all
> of them. In any case, I think I at least found why it got sent into the
> retry category. I will try to debug that error
>
> Transport: |/usr/bin/procmail error -m: > /dev/null:Imailadm@??? 0 0
> Child process of address_pipe transport returned 73 (could mean can't
> create output file) from comma
>
> Probably just some procmail thing. Not sure yet. But I didn't want anyone
> to spend anytime on this message pointing me to exinext.
>
> Sorry for the message. (You always find a better clue right after you hit
> that send button!)
>
> --Brett
>
> On Wednesday 18 December 2002 12:22, Brett Thorson wrote:
> > This is something new that just started happening, so maybe I just never
> > ran the system this hard, but I was hoping I could get some advice.
> >
> > I have i.org in queue domains. Which means that every message that comes
> > in has to wait for a queue run in order to get processed. That's
> > normally what happens. The first queue run comes by and it gets
> > processed. But I noticed a bunch of these sitting in the queue, and this
> > is what the log says.
> >
> > I think I understand the queue domains, and the retry times. What I
> > can't figure out is why the two are combined this time. How come it fell
> > into retry mode. Surely it could have delivered the message to procmail.
> > Why did it bother with a retry? It doesn't appear to have failed the
> > first time. Is there something else I should be looking at?
> >
> > Thanks much (and I mean it, having the developer and kinds folks like
> > Nico here really helps!!)
> >
> > --Brett
> >
> >
> > 2002-12-18 10:57:22 18OgZW-0006eC-00 <= owner-i@??? U=majordomo P=local
> > S=26640 2002-12-18 10:57:22 18OgZW-0006eC-00 == i-approval@??? routing
> > defer (-55): domain is in queue_domains 2002-12-18 10:58:21
> > 18OgZW-0006eC-00 == |/usr/bin/procmail -m /home/Imailadm/.procmailrc ||
> > exit 75 (Imailadm@???) <i-approval@???> R=userforward
> > T=address_pipe defer (-52): Retry time not yet reached 2002-12-18
> > 10:59:18 18OgZW-0006eC-00 == |/usr/bin/procmail -m
> > /home/Imailadm/.procmailrc || exit 75 (Imailadm@???)
> > <i-approval@???> R=userforward
> > T=address_pipe defer (-52): Retry time not yet reached 2002-12-18
> > 11:00:47 18OgZW-0006eC-00 == |/usr/bin/procmail -m
> > /home/Imailadm/.procmailrc || exit 75 (Imailadm@???)
> > <i-approval@???> R=userforward
> > T=address_pipe defer (-52): Retry time not yet reached
