Re: Exim: Different mail retry times depending upon response from remote host...
Craig Sanders wrote:
Because, like you mentioned later in your message, not all mailers give
proper responses. For example, I've see a lot of 5xx codes where the
verbal explanation is that the user is over quota.
On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote:
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
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.
But the *real* problem, I guess, is that I'm seeing so many 5xx's in
/var/spool/exim/msglog at *all*. If the sender address is bogus, the
bounce notification just hangs around forever, it seems. I'd like to be
able to give bounce notifications avout 4 hours to be delivered and
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.
Except write a script, I guess. :)
Well, I haven't tweaked our config too much... BUT.... it's the config
file from when we switched to Exim about 4 years ago, and I haven't
allowed Debian to overwrite it with a new one (lest we lose our mods to
the config file). So, it might be time to get a new config file and move
our changes over by hand. But... if we're going through that much
trouble.... geez... I'd just switch to Courier.
one possibility is that there is some error in your configuration which is
making permanent errors be treated as temporary (4xx) errors,