Did you try... oh, I dunno, *asking* yandex ?
They have logs that can tell you what happens; you don't.
J.
Yes, I did.
ya-dump.cap was captured by yandex support. They told to me that have "conversation with mx.tehstroi.ru[81.25.172.91] timed out while sending message body" errors. Also they suppose that problem is on my side or on my ISP.
Here is a fragment from the second file.
05:01:10.500421 81.25.172.91.25 > 95.108.130.119.52679: . ack 30840 win 64400 (DF)
05:01:10.500436 95.108.130.119.52679 > 81.25.172.91.25: . 49040:50440(1400) ack 255 win 6432 (DF)
05:01:10.500440 95.108.130.119.52679 > 81.25.172.91.25: . 50440:51840(1400) ack 255 win 6432 (DF)
05:01:10.500442 95.108.130.119.52679 > 81.25.172.91.25: . 51840:53240(1400) ack 255 win 6432 (DF)
05:01:10.751519 95.108.130.119.52679 > 81.25.172.91.25: . 30840:32240(1400) ack 255 win 6432 (DF)
At 05:01:10.500421 the client at 95.108.130.119 receives an ack
for data before offset 30840, so it resends the segment starting
at 30840 after waiting for 0.25 second (at 05:01:10.751519).
This is typical for the remainder of the session. Each time the
client 95.108.130.119 receives an ack for something that it sent
long ago, the client resends the next segment with a delay that
increases to 0.5s, 1s, and so on.
Your machine is announcing a large TCP window, but I suspect that
most of that is being dropped while it sits in some router queue
because the next hop is after a **very** slow network link.
The workaround then is don't announce a huge TCP window size.
With Postfix 2.6 and later, this goes like:
# postconf -e master_service_disable=inet
# postfix reload
# postconf -e tcp_windowsize=14000 master_service_disable=
# postfix reload
If you run an older Postfix, you will have to tweak your
local kernel in a manner that is very system and version
specific.
Wietse