Dotaz: Postfix: timed out while sending message body

[Jiřík 1435]

Dobry den, na Ubuntu 10.04 mam nainstalovan Postfix (version 2.7.0) V posledni dobe se mi stava ze pri posilani emailu na jeden konkretni postovni server dostanu nasledujici hlaseni:

May 30 08:54:48 sysel postfix/smtp[6613]: 099CA80A52: to=xxx.xxx@xxx.sk,
relay=xxx.xxx.sk[213.81.132.178]:25, delay=1705, 
delays=1460/0.07/2.5/243, dsn=4.4.2, status=deferred (conversation with xx.xx.sk[xxx.xxx.xxx.xxx] 
timed out while sending message body)

Nektere emaily (odeslane z Outlook klienta) proste nikdy nedorazi. Prumerna velikost emaily je 1MB. Uz sem zkousel zvednout dvojnasobne hodnoty nasledujich parametru:

smtp_data_done_timeout
smtp_data_xfer_timeout
smtp_data_init_timeout

bezvysledne. Cilovy postovni server je Lotus Domino Release 8.5.2. Budu vdecny za jakoukoliv radu.

Odpovědi

[linuxik]

Ahoj,

problem bude na druhe strane, pripadne nekde na siti. Nevypada to na problem s postfixem, druha strana proste prestane odpovidat.

[Jiřík 1435]

To sem si mysle take. Nicmene faktem je, ze pokud email ktery nedojde ze zmineneho duvodu, preposlu pres gmail tak dojde

[planking]

Problém je díky nízké odchozí rychlosti na tvém serveru. Čili první varianta je prodloužit time-out na cílovém serveru, což těžko půjde. Druhá varianta je zvýšit rychlost odchozího spojení. Třetí varianta je posílat krátké maily, tak do 500 KB. Řekl bych, že odchozí rychlost máš tak 128kbit.

[Jiřík 1435]

Odchozi i prichozi rychlost je 10 Mbit/s. Denne server preposle cca 1000 emailu. Email 10 MB neni absolutne problem.

[pupu]

Ja bych tam zkusil pustit sniffer a dival se, co to presne znamena, ze spadne spojeni. Osobne to odhaduji bud na nejaky uzasne genialni smtp fixup na PIXu, nebo specialni predstavu o fungovani smtp na strane toho Domina.

[Jiřík 1435]

Přílohy:

• tcpdump.txt (48020 bytů)
• tcpdump.txt (48020 bytů)

Musim priznak ze se vypisu tcpdump prilis nevyznam. Nez si to nastuduji mohl by jste se na ten vypis podivat vy (viz. priloha). Snad to nejak pomuze. Diky

[pupu]

Tohle vypada na sitovy problem. Ztraceji se pakety. TCP se to snazi sesynchronizovat, ale nejak se nedari a spojeni ve finale upadne. To je zajimave... co to je za linku? Z tohohle vypisu se neda poznat pricina. Hledal bych nekde na sitovych zarizenich po ceste.

[Jiřík 1435]

Pokud by byl problem na nejakem sitovem zarizeni tak by to musel byt relativne casty jev ne ? Problem se vsak tyka pouze jednoho ciloveho postovniho serveru. Navic jsem zjistil ze problemy maji pouze ty emaily ktere jsou odeslany z Outlooku 2007 a email navic obsahuji nekolik vlozenych printscreen-u. Neni mozne ze na tom Dominu muze bezet nejaky content filter ktery ten email skenuje jiz behem smtp komunikace a nejak "hapruje" ?

[pupu]

Podle toho tcpdumpu to tak nevypada

[Jiřík 1435]

Zda se ze je problem s firewallem na mem stroji ? Kdyz zapnu nasledujici minimalni firewall

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

for port in 22332 ftp ftp-data 25 993 990 http https ; do
	iptables -A INPUT -i eth0 -p tcp --dport $port -j ACCEPT
done

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

iptables -A INPUT -p tcp -j LOG --log-prefix "~~~~~FIREWALL~~~~~"

Tak se komunikace s danym serverem dostane prave az k pravidlu "~~~~~~FIRWALL~~~~~" Viz. vypis ze syslogu

Jun 14 08:03:02 sysel kernel: [322603.633710] ~~~~~FIREWALL~~~~~IN=eth0 OUT= MAC=00:50:56:8f:74:6d:00:21:59:4e:66:c7:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=52 TOS=0x00 PREC=0x00 TTL=119 ID=18217 DF PROTO=TCP SPT=25 DPT=51811 WINDOW=64240 RES=0x00 ACK FIN URGP=0

Nevite proc ?

[klepeto]

Tohle ovsem zakaze icmp a to je spatne. Povolit aspon tohle:

DROP       icmp -f  eth0   *       0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 0
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 4
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 8
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 11
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 0
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 1
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 2
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 3
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 4
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 9
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 10
ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 code 13
DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

[Jiřík 1435]

ICMP pakety standardne povoluji. Neuvedl jsem je pouze v tomto minimalnim testovacim firewallu. Zarazi mne ze v polovicce pripadu kdy je zahajena SMTP komunikace (povolen port 25) z meho serveru neni vysledna komunikace s cilovym serverem propustena pravidlem iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[klepeto]

Ted koukam, ze tak je asi opravdu nastaven don't fragment priznak, takze je mozne, ze provider u jednoho z vas ma spatne nastaven nejaky router:

http://en.wikipedia.org/wiki/Path_MTU_Discovery

Tohle by mohlo pomoci:

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu 

[klepeto]

respektive samozrejme doplnene o prislusne -d a --dport atd.

[Jiřík 1435]

Nepomohlo. Ps pokud na konec toho firewallu pridam tento radek

iptables -A INPUT -p tcp -s IP_CILOVEHO_POST_SERVERU -j ACEPT

vse projde jak ma.

[klepeto]

Symptomy sedi, ja bych hledal timto smerem. Napr. jste di jist, ze prijimate fragmenty?

[Jiřík 1435]

Myslim ze ano. Ve firewallu mam toto pravidlo:

iptables -A INPUT -i eth0 -p icmp --icmp-type fragmentation-needed -j ACCEPT

[klepeto]

Jinak k otazce - muze jit napr. o fragmenty (z hlavy to nepoznam)

[Jiřík 1435]

A co by jste potreboval k tomu aby jste to poznal ?