Re: recipient verify defer (making calloout connection): T=remote_smtp Cannot assign requested address

On 2025/11/07 8:54 PM, Marc MERLIN via Exim-users wrote:
> Logs showing when things work, below.  Any idea how I can capture this better or what could be
> going wrong?

Actually, that had its own problem:

11:38:13 2598836  TFO mode sendto, no data: EINPROGRESS
11:38:13 2598836 connected
11:38:13 2598836 try option helo_data
11:38:13 2598836  â•­considering: $primary_hostname
11:38:13 2598836  ├──────value: mail1.merlins.org
11:38:13 2598836  ├───expanded: $primary_hostname
11:38:13 2598836  ╰─────result: mail1.merlins.org
11:38:24 2598836   SMTP(Connection timed out)<<

(apart from your pastebin not handling UTF-8 !   If you have to, do no-utf8 debug)

It was trying to initiate a TCP connection, and the connect timed out.
Just below, we see:

11:38:24 2598836   H=(foo.bar) [24.6.49.44]:44516 I=[209.81.13.136]:10026 Warning: ACL "warn" statement skipped: condition test deferred: Could not complete sender verify callout

So it was a sender-verify callout being done.

The connection was:

11:38:13 2598836 Connecting to mail.rapidgrovelc.com [194.156.89.55]:25 from 209.81.13.136 ...

and
11:38:13 2598836    mail.rapidgrovelc.com 194.156.89.55 MX=10


So, at first sight it's not your problem but theirs.
You could manually probe that IP, port 25; presumably you'll
similarly fail to get a connection unless it was a temporary outage.

---------
Going back to the recipient verify defer - Cannot assign requested address...
that would be a problem on your system.  It it heavily loaded?  My first
thought would be the assignment of the local port along with the IP being
used for the outbound interface, and the bind syscall failing due to
ephemeral port exhaustion.   Any system-wide settings reserving ports
could be reducing the pool available, too (I used to see extreme examples
of that in a previous $JOB, associated with some major software packages...).


How to get more info?   Well, there's the ACL-driven speculative debug facility.
Start debug (to file) early on in the life of a message-handling, and then
discard it later if all has gone well past the roughly-determined danger point.

You'll still end up having to winnow the debug file, probably.  Start with the PID.
Consider also enabling millisecond timestamps.
-- 
Cheers,
   Jeremy

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/