We log all failed addresses and after 3 fails add the address to our bad
address list, so delivery is not attempted again. Not certain about
success percentages but they are pretty good I think because of the
above. We also have some basic retry rules in place to cover
graylisting, other defers, failures and everything times out after 2 days.
I would be very interested in any tips you have regarding retry rules.
David
W B Hacker wrote:
> Mr David Robertson wrote:
>> These machines have recently been upgraded, 3days ago. New hardware and
>> OS version. They replaced machines that were 3yrs old that had been
>> running the same configuration for that time without a problem.
>>
>> I have indeed fixed the problem by reverting to a normal -q20m but
>> thanks for the info. I think the problem may have been caused by
>> FreeBSD 7.1 being far better at handling multi cpu systems and process
>> running into each other (big guess).
>>
>> These servers are dumps that handle failed mail. So the cron job was a
>> brutal way of trying one last delivery and far quicker than -q20m when
>> you know the queue is going to be large and very slow.
>>
>> David
>>
>
> I'd be interested in what percentage of previously-failed traffic they
> manage to eventually deliver - and why that portion failed on the primary.
>
> Our retry rules take care of 'legitimate' greylisting w/o much load, so
> the only thing we ordinarily see as ND's are the odd 'tmda' or sputnik -
> left for the individual sender to deal with, or NOT.
>
> All else is not *ever* going to get thru - 'least not 'til a mis-spelled
> address is manually corrected.
>
> Bill
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.237 / Virus Database: 270.10.25/1956 - Release Date: 02/16/09 18:31:00
>
