Seznam k nám nedoručí poštu

[RDa]

Ahoj, nepotkal nekdo tento problem?

Kód: [Vybrat]

Aug 27 00:07:24 [postfix/smtpd] connect from mxm2.seznam.cz[77.75.76.45]
Aug 27 00:07:24 [postfix/smtpd] lost connection after CONNECT from mxm2.seznam.cz[77.75.76.45]
Aug 27 00:07:24 [postfix/smtpd] disconnect from mxm2.seznam.cz[77.75.76.45]

Aug 27 00:08:13 [postfix/smtpd] connect from mxf1.seznam.cz[77.75.72.123]
Aug 27 00:08:13 [postfix/smtpd] lost connection after CONNECT from mxf1.seznam.cz[77.75.72.123]
Aug 27 00:08:13 [postfix/smtpd] disconnect from mxf1.seznam.cz[77.75.72.123]

Aug 27 00:08:25 [postfix/smtpd] connect from mxs2.seznam.cz[77.75.76.125]
Aug 27 00:08:25 [postfix/smtpd] lost connection after CONNECT from mxs2.seznam.cz[77.75.76.125]
Aug 27 00:08:25 [postfix/smtpd] disconnect from mxs2.seznam.cz[77.75.76.125]

TCPDUMP rika ze po pripojeni se posle nase hlavicka, nacez prijde reset (odpojeni) iniciovane od seznamu. Dela to nas stroj po rebootu na novejsi jadro - a dle grepu z logu na tento typ chyby jsou to vsechno IP adresy patrici seznamu. Firewall neobsahuje krome povoleni otevrenych portu nic jineho. Jine SMTP k nam vesele dorucuji.

[Reklama]

[Jimm]

Trocha logiky. Seznam posle reset spojeni, muze za to moci vase jadro? A ze ne.... Je treba overit v logu po cem presne se odpoji, pravdepodobne vracite nejaky nesmysl v ehlo nebo tak.

[RDa]

Pokusem pres telnet:

Kód: [Vybrat]

220 smtp.*******.com ESMTP Postfix
* je domena. Vice se smerem na Seznam neposle ani podle tcpdumpu

[Lol Phirae]

No a co? Aspoň chodí míň spamu...

P.S. Seznam - větší sračku neznám. 

[Filip Jirsák]

To jméno, které vrací váš server, se přes A/AAAA záznam překládá na IP adresu, na které byl server kontaktován? Není v tom výstupu tcpdumpu vidět nějaká neobvyklá prodleva? Bez toho výstupu tcpdumpu vám asi těžko někdo poradí, bylo by dobré ho sem vložit.

[Reklama]

[RDa]

TCP dump zde:

Kód: [Vybrat]

15:10:00.683283 IP 77.75.76.125.50900 > 77.93.220.62.25: Flags [S], seq 3291963558, win 14600, options [mss 1460,sackOK,TS val 2539456677 ecr 0,nop,wscale 7], length 0
15:10:00.683314 IP 77.93.220.62.25 > 77.75.76.125.50900: Flags [S.], seq 2561200165, ack 3291963559, win 28960, options [mss 1460,sackOK,TS val 141322250 ecr 2539456677,nop,wscale 7], length 0
15:10:00.687438 IP 77.75.76.125.50900 > 77.93.220.62.25: Flags [.], ack 1, win 115, options [nop,nop,TS val 2539456677 ecr 141322250], length 0
15:10:00.688375 IP 77.93.220.62.25 > 77.75.76.125.50900: Flags [P.], seq 1:37, ack 1, win 227, options [nop,nop,TS val 141322255 ecr 2539456677], length 36
15:10:00.693152 IP 77.75.76.125.50900 > 77.93.220.62.25: Flags [R.], seq 1, ack 37, win 0, length 0
15:10:06.284709 IP 77.75.76.125.59138 > 77.93.220.62.25: Flags [F.], seq 2779550629, ack 2815726875, win 115, options [nop,nop,TS val 2367438756 ecr 141267793], length 0
15:10:06.494356 IP 77.75.76.125.59138 > 77.93.220.62.25: Flags [F.], seq 0, ack 1, win 115, options [nop,nop,TS val 2367438777 ecr 141267793], length 0
15:10:06.914353 IP 77.75.76.125.59138 > 77.93.220.62.25: Flags [F.], seq 0, ack 1, win 115, options [nop,nop,TS val 2367438819 ecr 141267793], length 0
15:10:07.754593 IP 77.75.76.125.59138 > 77.93.220.62.25: Flags [F.], seq 0, ack 1, win 115, options [nop,nop,TS val 2367438903 ecr 141267793], length 0
15:10:09.434901 IP 77.75.76.125.59138 > 77.93.220.62.25: Flags [F.], seq 0, ack 1, win 115, options [nop,nop,TS val 2367439071 ecr 141267793], length 0
15:10:12.805023 IP 77.75.76.125.59138 > 77.93.220.62.25: Flags [F.], seq 0, ack 1, win 115, options [nop,nop,TS val 2367439408 ecr 141267793], length 0

Seznam tvrdi, ze jim do 5s neodpovim na jejich identifikaci a pak se odpouji, ale ona zadna neprijde. Je tam jenom ten divny RST... a pak 5s na to samozrejme FIN.

[Filip Jirsák]

V tom výpisu máte jedno spojení, které je ukončené ihned tímto paketem:

Kód: [Vybrat]

15:10:00.693152 IP 77.75.76.125.50900 > 77.93.220.62.25: Flags [R.], seq 1, ack 37, win 0, length 0
Pak po pěti sekundách divný konec jiného spojení (je navázané z jiného portu). Což je samo o sobě divné, poštovní server normálně nenavazuje víc spojení k jednomu serveru zároveň, nedává to žádný smysl.

Máte zachycený i počátek toho druhého spojení? Mně to totiž připadá, jakoby ten resetovací paket poslal někdo jiný a komunikaci se Seznamem vám tím odstřelil. Vy tím pádem nijak neodpovíte a Seznam po pěti sekundách to spojení ukončí. Divná je ale ta změna zdrojového portu, to by tam muselo být víc manipulace s tím spojením, než jenom vložení toho resetu.

Je to divné, ale je to jediný výklad, který mne napadá, a který by byl zároveň v souladu s ostatními tvrzeními u dotazu. Nemůžete ten provoz odchytávat ještě někde dřív, než na serveru, třeba na routeru?

[RDa]

To byly asi dve jina spojeni, v noci jsem jich par odchytil (porad jen na svem serveru) a uz to ma konzistentni porty, ale jsou tam dva resety:

Kód: [Vybrat]

00:38:32.706410 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [S], seq 2748942828, win 14600, options [mss 1460,sackOK,TS val 530689888 ecr 0,nop,wscale 7], length 0
00:38:32.706440 IP 77.93.220.62.25 > 77.75.72.123.55099: Flags [S.], seq 3308101770, ack 2748942829, win 28960, options [mss 1460,sackOK,TS val 261836017 ecr 530689888,nop,wscale 7], length 0
00:38:32.710342 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [.], ack 1, win 115, options [nop,nop,TS val 530689888 ecr 261836017], length 0
00:38:32.711363 IP 77.93.220.62.25 > 77.75.72.123.55099: Flags [P.], seq 1:37, ack 1, win 227, options [nop,nop,TS val 261836022 ecr 530689888], length 36
00:38:32.715616 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [R.], seq 1, ack 37, win 0, length 0
00:39:32.770436 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530695894 ecr 261836017], length 0
00:39:32.971595 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530695915 ecr 261836017], length 0
00:39:33.391598 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530695957 ecr 261836017], length 0
00:39:34.231546 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530696041 ecr 261836017], length 0
00:39:35.911607 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530696209 ecr 261836017], length 0
00:39:39.281704 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530696546 ecr 261836017], length 0
00:39:46.021857 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530697220 ecr 261836017], length 0
00:39:59.502013 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530698568 ecr 261836017], length 0
00:40:26.462368 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 530701264 ecr 261836017], length 0
00:45:26.734869 IP 77.75.72.123.55099 > 77.93.220.62.25: Flags [R.], seq 2, ack 1, win 0, length 0


[Filip Jirsák]

Pořád je to ale FIN po RST, což nedává smysl – stále to vypadá, jakoby Seznam o tom resetu vůbec nevěděl, tj. jako by byl do toho spojení vložen navíc někým jiným. Není to nějaká antispamová featura vašeho ISP?
Tenhle výpis má logiku, až na ten první reset – Seznam se pokouší spojení po minutě neaktivity regulérně ukončit, a když se mu to nepodaří, po dalších pěti minutách spojení natvrdo resetuje.
Pokud by ten první reset posílal Seznam, je to jejich chyba. Pokud se tam dostává později, je potřeba vypátrat, kde – zda to dělá váš ISP nebo až vaše síťová infrastruktura. Chtělo by to dump z hranice vaší sítě – a pokud to bude i tam, měl byste to řešit s vaším ISP. Že by správně trefil sekvenční číslo útočník úplně odjinud a poslal ten správný paket ve správné desetině sekundy, to se mi nezdá pravděpodobné.

[Jimm]

Já bych si k borcům hlavně dal e-maily, to by byla hitparáda.  2 dny bez e-mailů ze seznamu, který je sice běsný, ale to nic nemění na tom že je v čr z freemailů asi nejpoužívanější...

[Fhj]

Drop IDENTu?

[daysleeper]

Střílím od boku, ale mně tohle (RST po navázání spojení) dělalo pop3.centrum.cz, protože moje (sdílená) IP byla na nějakém (veřejném) blacklistu, který server používal, ale neměl nad ním kontrolu. centrum s tím odmítlo cokoliv dělat a odkázalo mě na provozovatele toho blacklistu, ať se dohodnu s ním.

[Jimm]

Nevím, ale pokud by se to odpojovalo na základě blacklistu, proč by se to vůbec připojovalo?  Ale netuším nic o Seznamovském mailu, na čem jede a nehodlám to ani měnit. 

[Filip Jirsák]

Pokud by to byl blacklist na základě IP adresy, ani by spojení nenavazoval. Mohla by to být nějaká kontrola (nebo blacklist) na základě doménového jména, které vrací SMTP server v uvítací zprávě. Ale pokud by Seznam resetoval spojení, proč by si dál myslel, že má spojení otevřené, a pokoušel se ho za minutu regulérně ukončit pomocí FIN?

[Dadko]

Chcelo by to asi skontaktovat ISP a zistit, ci ma rovnaky problem so seznamom. Ak nie, tak nejako s jeho pomocou spravit dump packetov na routri pred tvojim. Blacklist si myslim nehrozi. Skor to bude mozno nieco este pred routrom, nejaky packet co sa k nemu ani nedostane. Kludne to moze byt napr. filtrovany ident.