Mailing List Archive

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?
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

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



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 07/08/2020 11:25, Cyborg via Exim-users wrote:
> 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 think you'll find that the server sent a FIN as part of frame #92.

I'm not too surprised that an IOT stack would not be TCP-standards
confirming, but I'm glad to hear that it was fixed in an update.

Laura, if your scenario matches this then you have bad software
on at least one end. I'd still like to see the logging, in full
not just described in your words, from both systems.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/