Did you try... oh, I dunno, *asking* yandex ?
They have logs that can tell you what happens; you don't.

J.

> Did you try... oh, I dunno, *asking* yandex ?
> They have logs that can tell you what happens; you don't.

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.

> I have a problem with receiving mail from yandex (large mail service).
>
> May 21 13:30:09 mx postfix/smtpd[77115]: timeout after DATA (47440 bytes) from forward11.mail.yandex.net[95.108.130.93]
> May 21 13:31:56 mx postfix/smtpd[76924]: lost connection after DATA (33439 bytes) from forward3.mail.yandex.net[77.88.46.8]
> May 21 13:32:39 mx postfix/smtpd[77207]: lost connection after DATA (75160 bytes) from forward14.mail.yandex.net[95.108.130.92]
>
> I have no problem with receiving mail from other servers.
> I have no problem when sending mail to any servers including yandex.
> At different location I have another postfix mail server that receiving mail from yandex.
>
> I tried to decrease MTU size to 1000. Also I tried switch to other ISP. With no result in both cases.
>

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