Re: [exim] Strange SMTP problem, no completed to sender

Am 07.08.20 um 11:44 schrieb Jeremy Harris via Exim-users:
> On 06/08/2020 17:54, Laura Williamson via Exim-users wrote:
>> * Remote sender sends email to a local user
>>
>> * Mail is delivered to local user
>>
>> but sometimes exim doesn't close the connection to the senders SMTP
>> server correctly (believe there is some sort of handshake that fails,
>> message accepted or similar), the sender SMTP therefore keeps sending
>> the same message over and over again.
> What do your receiving system's logs show? Sending system?

If I may do a prognosis:

a) You won't find anything unusual in the logs, whatever debug level you
choose.

b) When TCPDUMP is running, you will see no problem, except one
"missing" FIN packet.

We had this a few weeks ago with an IoT device, same behaviour as above.
The IoT device had some old embbeded linux stack running,
which reacted strange to the FIN handshake both TCP/IP stacks did. An
update of that device fixed the issue.

@Laura: please run a TCPDUMP of a clear text message transfer ( to avoid
SSL problems for now )  and post the End of it beginning with "QUIT"
till the end. You can replace sender and receiver ip with placeholders
if you like, but we definatly need to know who is who.

$# tcpdump -n -n -a -s 8192  host ip.of.sender and port 25

If you use tcpdump with -w /tmp/port25.dump  and import the log into
Wireshark, it will look like this, but the native TCPDUMP Output is fine
also:


91    1.619741    X  83.246.80.144    SMTP    60    C: QUIT
92    1.620504    83.246.80.144  X    SMTP    102  S: 221
{serverhostname} closing connection
94    1.669586    X  83.246.80.144    TCP       60    2872 → 25 [FIN,
ACK] Seq=252 Ack=521 Win=4380 Len=0
95    1.669610    83.246.80.144  X    TCP       54    25 → 2872 [ACK]
Seq=521 Ack=253 Win=64046 Len=0

As this is basically the correct procedure to close a connection, as the
client (X) sends a FIN,ACK and the server reacts with an ACK. But, the
clients mta or TCP/IP stack awaits something else (probably the FIN the
server would send, if it hadn't gotten the FIN,ACK itself). I have no
clue what it was, we never found out, but a later os version for the
same IoT device, fixed the problem afaik. So please feel free to send
your TCPDUMP of the last packets send for this connection.

Hint: Wireshark can filter for tcp streams, means single connections in
case you catch more than one transmission from the same host with your
TCPDUMP.

best regards,
Marius