Re: Exim: Different mail retry times depending upon response from remote host...
On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote:
> You don't have to be a rocket scientist to realize that the following
> remote mailer messages give varying degrees of optimism regarding future
> delivery:
>
> 550 Requested action not taken: mailbox unavailable
> 452 Mailbox full
> 452 Insufficient disk space; try again later
> 421 Too many concurrent SMTP connections; please try again later.
>
> With the first, you're pretty sure that the problem is *not* going to be
> corrected in the next few days. Meanwhile, the others give you some hope
> in waiting.
>
> Unfortunately, I haven't seen anything in Exim that lets you customize
> it's retry behavior based upon this. It does offer an "error" field in
> the retry section, but it's only for some silly hard-coded failure types.
why should there be?
All 5xx codes are permanent failures. the MTA should bounce back to sender
immediately.
All 4xx codes are temporary failures. the MTA should (optionally) retry later,
but eventually bounce back to sender if not delivered in X hours/days.
> So, I wrote a little script that goes through all of the msglog files and
> finds good candidates to toss (ie, "No such user", "Account Terminated",
> etc.). With just a day's worth of tweaking the script, I've managed to get
> the pending queue down to about 1/3 of what it was.
these sound like 5xx errors, rather than 4xx. exim should be bouncing these,
if the remote systems are issuing the correct error codes. if they aren't,
there's little you can do about it.
one possibility is that there is some error in your configuration which is
making permanent errors be treated as temporary (4xx) errors, similar to
postfix's "soft_bounce" feature...a useful feature while testing and debugging,
but not what you want for normal use. i don't know what this option is called
in exim (it's been a few years since i did much with it).
> But I figured I'd ask... does anybody already have a script for doing this
> (or maybe a better way altogether, since this script has to be explicitly run
> periodically)?
it shouldn't be necessary.
craig
Reply to: