Now, the issue is what here?
timing hazards. client A talks to server B, server B talks to server C,
which is the MX for the originator's email address.
if server C doesn't respond until near the end of server B's timeout
(due to server load or network congestion or whatever), server B
will give up. when client A retries, often (in my experience) the same
thing happens again. that is, a lot of the times the delays aren't
randomly scattered (which would be recoverable) but are clustered for
certian sender addresses.
SMTP as currently specified wasn't designed to handle real-time
callbacks. for instance, there is a single set of timeout limits
for all servers.
This is why it works for thousands of our installations with many HAPPY
faces and little to know false positives.
most of my thousands of users had no complaints. but a few were extremely
unhappy, to say the least, when their mail stopped working.
my situation is probably different than yours. I run a server which
provides two services to its users: mail forwarding and delivery of a
moderated weekly digest. the callbacks were used to filter out spam
and viruses from mail sent to forwarding addresses, from digest
messages, and from service requests. the users are scattered all over
the world, mostly in academic institutions, but some have better
connectivity than others.
when our users have a complaint, they're not usually able to resolve
it at their site. it sounds like your customers are more likely to
be sites than individual users, and that your customers' problems are
more likely to be site-wide than my customers' problems.
This is my only comment about this and I will steer clear of this thread. I
just wanted to point out that the real experts are in the field actually
putting this stuff to work in practice - it is not theory, a raised back
hair or a devil on your shoulder whispering into your ear.
and some of the real experts are getting unfavorable results.
Keith