Occasionally, an attempt to verify a sender address (e.g at yahoo.com)
via callout produces a response:
421 VS14-RT5 Mailbox bounce arrival rate exceeds system limit (#4.2.2)
We'll then defer the transaction, and the offering MTA will try again,
and we'll try another callout, and so on. This can go on for days,
until the offering MTA finally gives up.
Once this response is received, it seems pretty persistent. Is anyone
aware, please, of whether this response is only specific to the email
address which we're trying to verify - or whether yahoo are getting
upset at our particular IP address for repeatedly trying callouts?
(To be honest, I tried raising this point on this list about a year
back, but the discussion went off on a tangent and didn't really
produce usable results. Not that I'm complaining, but I thought
perhaps some folk might have come up with an idea since, and be
willing to share it.)
Let's try to develop the issue a bit...
The exim relevance would seem to be a possible desire to take special
actions in the event of a 4xx response to a callout. I've seen other
instances where callout has received a 4xx response, e.g some MTAs
even report non-existent addresses via a 4xx status - here's an
example of that right here:
RCPT to postmaster was refused:
450 <postmaster@???>: Recipient address rejected: unknow user
I'm not wanting to treat all 4xx responses to callout as fatal, pretty
obviously - but it would be nice to at least have the option to take
firmer action, rather than leaving the transaction pointlessly
retrying until it expires.
thanks for any ideas.
