It can probably provide useful information in the logs, but this doesn't justify that 30s timeout. In exim 4.61, the timeout was decreased from 30s to 5s. See that comment in a Debian Etch exim.conf:

# The settings below, which are actually the same as the defaults in the
# code, cause Exim to make RFC 1413 (ident) callbacks for all incoming SMTP
# calls. You can limit the hosts to which these calls are made, and/or change
# the timeout that is used. If you set the timeout to zero, all RFC 1413 calls
# are disabled. RFC 1413 calls are cheap and can provide useful information
# for tracing problem messages, but some hosts and firewalls are
# misconfigured to drop the requests instead of either answering or
# rejecting them. This can result in a timeout instead of an immediate refused
# connection, leading to delays on starting up SMTP sessions. (The default was
# reduced from 30s to 5s for release 4.61.)
# rfc1413_hosts = *
# rfc1413_query_timeout = 5s

I suggest we done the same: decrease to 5s. This would solve the problem of sender callouts failing.

Another problem is that the check seems to have a problem receiving RST packets: my server doesn't just drop the ident packets, it refuses the connection. exim should detect that and stop retrying:
Capturing on eth0
0.000000 88.191.250.46 -> 80.248.208.235 TCP 58444 > auth [SYN] Seq=0 Len=0 MSS=1460 TSV=207597283 TSER=0 WS=0
0.000025 80.248.208.235 -> 88.191.250.46 TCP auth > 58444 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
2.990316 88.191.250.46 -> 80.248.208.235 TCP 58444 > auth [SYN] Seq=0 Len=0 MSS=1460 TSV=207597583 TSER=0 WS=0
2.990355 80.248.208.235 -> 88.191.250.46 TCP auth > 58444 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
8.990332 88.191.250.46 -> 80.248.208.235 TCP 58444 > auth [SYN] Seq=0 Len=0 MSS=1460 TSV=207598183 TSER=0 WS=0
8.990377 80.248.208.235 -> 88.191.250.46 TCP auth > 58444 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
20.990317 88.191.250.46 -> 80.248.208.235 TCP 58444 > auth [SYN] Seq=0 Len=0 MSS=1460 TSV=207599383 TSER=0 WS=0
20.990357 80.248.208.235 -> 88.191.250.46 TCP auth > 58444 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0

Could this be explained by a firewall configuration ?

I recently set up exim's sender verify callout to avoid some of the huge lot of spam I receive daily. When a remote SMTP connects to my server, my server checks if the sender address exists by connecting to the address's SMTP server, and issuing HELO, MAIL FROM, and RCPT TO commands.

A similar system has been implemented recently inside Debian, on an opt-in basis.

Since I set this up, I couldn't receive mail from gna anymore. I investigated the issue, and understood that when my server connects to mail.gna.org to check an address, it runs into a 30s timeout caused by the ident check on mail.gna.org:
rfc1413_hosts = *
rfc1413_query_timeout = 30s

Indeed, I see ident requests coming in, and connection being refused (I don't run an indent daemon). It's strange that mail.gna.org doesn't that the connection is refused, and continues to try to connect for 30s, but that's not the main issue, since the issue would be the same for servers which filter ident requests.

I think that the timeout for the ident check should be decreased to something like 5s, or the check should be completely removed (is it really of much use ?)

A list of other affected mail targets is available with

grep "451 Could not complete sender verify callout" /var/log/exim4/mainlog.1 /var/log/exim4/mainlog

Thank you