On 2023-06-03, Jeremy Harris via Exim-users <exim-users@???> wrote:
>>>> SMTP>> 421 london.jcbradfield.org lost input connection
>>>> LOG: lost_incoming_connection MAIN
>>>> unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s
>>>
>>> Good, that's as expected.
>>
>> Why is it expected? Shouldn't exim give up when it loses the outgoing
>> connection?
>
> Which is what is did. It shortcut the delay and
> got along to handling the lost connection, which is
> I think what you mean by "give up".
>
> But we want to know what happened for the previous
> RCPT TO.
I showed you. All the previous 90-odd RCPTs (apart from those which
were greylisted rather than denied, because they had valid localparts)
ended with
----------- end verify ------------
message: Unknown user
check delay = 5s
delay modifier requests 5-second delay
delay cancelled by peer close
deny: condition test succeeded in ACL "acl_check_rcpt"
end of ACL "acl_check_rcpt": DENY
SMTP>> 550 Unknown user
LOG: MAIN REJECT
H=([58.53.131.26]) [58.53.131.26] F=<g4ckp5go0l67ba@???> rejected RCPT <amazon@???>: no such user
I would expect exim to give up when it first encounters the "peer
close" condition on the outstream, and not wait until it detects
closure of the instream.
Given the behaviour of the attacker, the delay doesn't serve any
useful purpose anyway, but at least exiting on outstream close would
reduce the noise in the log file.
--
## 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/
