[Exim] sender-verify callouts which respond 4xx

It's happening sufficiently often to be a nuisance, that a callout[1]
to verify an envelope-sender gets the non-existence of the envelope
sender address reported by means of a 4xx status. Take today's
example:

sender verify defer for <ewccqyujeujrhx@???>: response to "RCPT
TO:<ewccqyujeujrhx@???>" from erica.mma.com.br [200.223.171.4]
was: 450 <ewccqyujeujrhs@???>: User unknown in local recipient
table

This of course results in a temp-fail then being returned from us to
the offering MTA (in this case at RCPT TO time, as you can see), and
that MTA will try over and over, on its normal retry schedule, while
we respond over and over by temp-failing it. And adding yet more
noise to the logs...

Typically, these are mails that have been accepted by one of our
users' accounts elsewhere, and are being forwarded to us. Direct spam
would usually either be rejected on other grounds (dnsRBLs etc.), or
the spammer wouldn't bother to retry.

It can be argued that the right place to stop this spam is at the MTA
which is relaying it, and that once it's been accepted on the user's
behalf, we should simply accept it and not try to play second-slip.
But frankly there is far too much of this stuff, I don't have any
influence over the anti-spam policy of these other sites, but I don't
want them to "leak" any more spam into our system than I can help.

I'm wondering how to handle these 4xx situations which - on inspection
- can be seen to be effectively a permanent failure. Is there some
way I can grab the result of this defer?

If the worst came to the worst, I suppose one could run a script
against the logs looking for this pattern, and blacklisting the
envelope senders in question. Messy, though. Easiest way out, for
sure, is to blacklist the domain which is returning the 4xx status;
but I'm not sure that the transgression really rates such a fierce
measure, and it surely could lead to some false-positives when bona
fide addresses in those domains want to send us genuine mail.

thanks for any thoughts


[1] just a routine recap that we don't do callout as a matter of
course, but only on a selective basis when there's some other
circumstances leading us to distrust the presented envelope-sender.
But once this has happened, the above retries are going to continue
until the attempt finally times-out at the offering MTA.