Many thanks. You make some very interesting points.
I like the cut of your jib ;-)
You may have talked me into some more aggressive retry rules.
Regards
David
W B Hacker wrote:
> Mr David Robertson wrote:
>> 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
>
> We are probably 'odd man out' on retry, but believe that:
>
> -- while smtp isn't supposed to be reliable or guaranteed in theory, in
> practice it works so well, and so often, that end-users believe it to be
> as certain as such things get.
>
> -- accordingly, we may cease retry in as little as 13 minutes for some
> servers.
>
> That allows the sender of a failed message a fighting chance to correct
> a bad address, ELSE, if important enough, pick up the phone or send a
> fax before scarpering off for a 3-day weekend or such.
>
> In any case - to be aware that the message did NOT make it while they
> still remember what they sent and why.
>
> Finding that out 3 or 4 days later is useless.
>
> Mind - it is near-as-dammit a transparent setting, as most mail gets
> thru in one go, and whatever is going to fail will almost always get a
> 5XX hard fail in the first minute or two.
>
> That which hits a 'defer' will get thru by the 4th attempt if not the
> second, ELSE never. Given the prevalence of bad-greylisting
> implementations, first retry is probably best made at no less than the
> five minute mark, give up and quit no more than twenty minutes.
>
> CAVEAT: As said - we're odd-man out.
>
> But even a 50-baud torn-tape operation didn't need 3 days to report a
> failure...
>
> HTH,
>
> Bill
>
>
>
>> 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
>>>
>
>
>
> ------------------------------------------------------------------------
>
>
> 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
>
