Autor: Alan J. Flavell Data: A: Exim users list Assumpte: [Exim] "Mailbox bounce arrival rate exceeds system limit" from yahoo
A situation which arises from time to time with callout to verify
the purported envelope sender, is that the mx for the domain responds
with this sort of answer:
421 VS14-RT5 Mailbox bounce arrival rate exceeds system limit (#4.2.2)
Short of ignoring temporary errors (with defer_ok), this seems to be a
self-perpetuating situation, in that we then give the sender a
temporary error - after a short delay they retry - we try the callout
again, and the domain's mx becomes increasingly convinced that we are
a nuisance...
Today's standoff situation, as it happens, was a sender presenting
some implausible-looking envelope sender address at yahoo.co.kr which,
when our exim attempts to check it with exim's callout, the callout
ends with a temporary failure, logged along the lines of:
[...] sender verify defer for <...@yahoo.co.kr>: Could not
complete sender verify callout
Now if I try the verification manually from the same host, I get the
response previously described:
421 VS14-RT5 Mailbox bounce arrival rate exceeds system limit (#4.2.2)
However, if I try the same manual verification from some _other_ host,
I get a result.
Presumably, if our exim continues to try this callout each time that
the sender retries, then the situation isn't likely to get any better
by itself?
This pattern isn't specific to yahoo.co.kr, it's just an example for
the purpose of discussion. Do folks have any kind of intelligent
strategy for handling this kind of situation, please? As I said, I'm
well aware that I could ignore the temporary error from the callout,
with a defer_ok parameter, (and hope to catch spam with some of our
other criteria), but to be honest I'm not sure why I should.
Obviously, some manual action is feasible in today's case, now that
the situation has been spotted, and such action will be taken, but I'm
asking more about possible automatic strategies for this kind of
problem.
