Re: Exim: Different mail retry times depending upon response from remote host...

[Joe Emenaker]

Craig Sanders wrote:

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

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.

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 
then, buh'bye.

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. :)

one possibility is that there is some error in your configuration which is
making permanent errors be treated as temporary (4xx) errors,
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.

- Joe

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]