On 13/05/2023 12:55, Andrew C Aitchison via Exim-users wrote:
> I would still like to know where the delay is actually happening;
> currently I guess it is somewhere in the authentication.
No, the client has tried an auth command which we responded "fail"
to, and then the client abandoned the TCP connection without
bothering to close it (let alone QUIT the SMTP layer session,
or (I expect) properly terminate the TLS session).
Because that's the cheap thing for an attacher to do.
Meantime, we're waiting for the next SMTP connand from the
client, because per SMTP standards the ball is in their court.
The delay is our SMTP command timeout. It is currently our
way of detecting this behaviour.
We could
- manipulate the SMTP command timeout, as you suggest
- run a shorter TCP keepalive probe delay. When it fires,
we hope to get a RST back from our first probe, assuming
a normal TCP stack at their end. But they could be running
a custom, so also reduce the number of probe tries before
we declare the TCP connection dead.
- Unilaterally send some probe data, again to try to elicit
a RST. This would be violating the SMTP protocol.
Perhaps a 421 SMTP response?
- Somehow exempt cnnection in this state from the
smtp_accept_max counting
--
Cheers,
Jeremy
I wish there was an IOCTL to send a keepalive probe.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
