Prev: redirecting non local accounts to their respective domainemail address
Next: dspam breaks return-path and to address/address extension
From: Jeroen Geilman on 17 Jun 2010 12:57 > 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. > Did you try... oh, I dunno, *asking* yandex ? They have logs that can tell you what happens; you don't. J.
From: Wietse Venema on 17 Jun 2010 15:25
Alexander Moisseev: [ Charset KOI8-R unsupported, converting... ] > 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. > > Postfix 2.7.0, FreeBSD 7.1-RELEASE > > Attached tcpdump files: > ts-dump.cap - from my postfix server > ya-dump.cap - from one of the yandex servers 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 |