Duplicitní zprávy ze Seznam.cz na Postfixu

[lobik]

Na server s s postfixem dovecotem a spamassinem mi chodí duplicitní zprávy (i 60 stejných zpráv). Vypadá to že dojde k vypršení timeoutu při příjmu a seznam posílá zprávy stále dokola. Z jiných domén to chodí v pořádku a z testovacího e-mailu na seznamu to taky přišlo v pořádku. Už jsem komunikoval s technikou podporou seznamu a zvedli timeout na 120 ale problém stále přetrvává. Asi mám něco špatně v mojí konfiguraci postfixu ale nemohu na to přijít. Mohl by mi někdo pomoci nebo navést na nějaké řešení? Díky

[Reklama]

[RDa]

Jako problem bych hledal v tom, proc predani zpravy na vas server trva minutu az dve.
Pomala sit?
Zasekany server?

Prijde mi celkem nesmyslny, aby vas server zpravu prijal a lokalni dorucovani probehlo, aniz by se stihl zaslat ten posledni paket, se stavovym kodem ze to prevzal/neprevzal.

[mikesznovu]

Tento problém jsem nikdy nezaznamenal (2 různé SMTP@25)
Nemáš nějaký plugin typu karma, tarpit? Který dokáže neznámé/prvně připojené odesilatele zbrzdit na až asi 40sec?

Máš nějaké BLACK listy atd? co když dáš seznam do whitelistu?

[František Ryšánek]

Taky něco takového provozuju,  a tenhle problém jsem ještě nepotkal.
Měl bych k tomu spoustu doplňujících otázek, na které se nesluší dávat veřejné odpovědi.
Popravdě něco takového řešit, znamená mít nejlépe hands-on přístup :-(
Uvedu pár otázek/nápadů, na které si sám odpovězte = nechci tady veřejně číst odpovědi:
- nemáte ten stroj s postfixem až za nějakým CPE firewallem, který může SMTP relace nějak netriviálně filtrovat/mrvit?
- zkoušel jste si típnout tcpdumpem záznam takové relace? Upozorňuji na možnost, na serveru típnout do souboru a následně prohlížet PCAP někde offline, v pohodlí vysokého rozlišení, v grafickém tcpdumpu. Típnout do souboru můžete jenom podmnožinu provozu, která Vás zajímá.
- koukal jste do logů Postfixu? /var/log/mail.log nebo tak něco. Obvykle na sebe dost vykecá.
- v /etc/postfix/main.cf (ev.též master.cf) všelijaké "checks", "restrictions" nebo "content_filter" klauzule... je toho hodně. Co třeba nějaký content filter typu "rbl check", který se doptává kamsi do dáli, a může při tom timeoutovat ? (Ale je to divné, konkrétně RBL check tuším vykopne, aniž by zdvořile odpověděl na EHLO.) Ony různé tyhle kontroly se dají zařadit do různých fází průchodu zprávy serverem.
- když občas něco někde blbě dlouho hnije a timeoutuje, stojí za to zkontrolovat, jestli běhá správně DNS na Vašem serveru = jestli když se zeptá, tak dostane hbitě odpověď. Třeba nějaký ten reverzní dotaz na adresu přistupujícího "klienta" (odesílajícího SMTP). Taky bejvalo něco jako služba "ident", která se na firewallu filtrovala stylem "reject", aby selhala hned...
- třeba Postgrey se mi takhle nikdy neprojevil.
- jak moc je to Vaše distro mainstreamové, vs. obskurní / "svoje"... Jak moc je to bleeding edge.
- jak rychle se ty opakované zprávy hromadí? Kolik času uplyne mezi dvěma zprávami?
- přemejšlím / nejsem si jist, jestli se tak nemůže chovat nějaký problém v konfiguraci lokálního doručování. Netuším, kdy přesně Postfix v SMTP řekne "OK message accepted for delivery".

Hele tohle se Vás náhodou netýká?

[McFly]

Chtělo by to vidět tu konfiguraci postfixu (ořezanou o citlivé údaje). Tip: špatná síť, blbé DNS, špatné kontroly v Postfixu, Spamassassinu, skvrny na slunci, atd. Log postfixu je dobro.

[Reklama]

[Wasper]

Chtělo by to vidět tu konfiguraci postfixu (ořezanou o citlivé údaje). Tip: špatná síť, blbé DNS, špatné kontroly v Postfixu, Spamassassinu, skvrny na slunci, atd. Log postfixu je dobro.

V minulosti jsem se s něčím podobným občas setkal taky, obvykle to bylo způsobené věcmi jako zrušený dnsbl v konfiguraci spamassassina, starý plugin který přestal pracovat a měl být vyhozen apod.
Chce to jak píšete, prolézt logy, pokud je ten mailserver nevytížený, klidně zkusit strace -f -p (popř si tam bloknout 25ku všude kromě seznamu etc.) apod.