Re: [exim] A Tight Exim Config

Jon Hardcastle wrote:
> Can I firstly apologise if this reply format is non-standard I struggeld to
> reply to that digest email; I think i will turn it off!
>
> Thank you for your reply to my email. When i say arrived I mean delivered. It
> is *all* about making sure with as much certainty as possible that the
> message has been delivered.
>
> How do the 'captains of industry' do this?

Largely 'not at all'. Pragmatically, with policy and procedure, not with smtp mods.

'Used to be' "with private wire, X.400 and bespoke MUA" - where one had a better
chance of insuring 'visible' reporting of delivery/NOT, and an integrated
MUA(equivalent) can report that a message had been opened onto the screen
whether the recipient wanted to admit it or not. (DaVinci on Novel MHS over
private-leased intranet)

Used all that to stop the then-popular 'I never got the message...' excuse.

smtp - despite the de-facto marvelous record of reliability it has grown for
itself, is 'best efforts' and makes no guarantees.

So - policy' - anything super-critical needs a 'Reply to sender with your
confirmation as soon as you read a [priority X | from department Z | any] .

> If i turn the retry details in
> exim right down and manage that myself will that work?

Yes - you can go against the convention and set to very few retry before fail
AND more critically - over a very short interval.

Hard-fail after a mere 13 minutes worked well for us.

It will fail to deliver now and then when a dodgy recipient or erratic link is
involved, but at least the sender will be AWARE of that within minutes and can
pick up the phone or send a fax same-day, not 4 days later.

CAVEAT: business decision, not a suggestion to change the smtp world.

> Alternatively does
> anyone parse the log to find the status of their message?
>
> Cheers.
>

Only when asked. With a near-as-dammit 'always' delivery record, those are rare
events.

Far more common to have complaints of non-RECEIPT wherein the sender can't be
bothered to get a fixed-IP and publish a valid PTR RR et al for his 'server', so
was rejected at connect time as a probable zombot.

HTH,

Bill Hacker