Dotaz: Postfix mě doručuje poštu spožděně

[Kall Ell]

Dobrý de, mám na debianu ech4.1(tusim) postfix a dorucuje me pozdě poštu.V logu je následující.

15:38 postfix/smtpd[26731] 672282A40BD: client=nejaky.mailserver.cz[ip]
15:38 postfix/cleanup[26734] 672282A40BD:massage-id=idzpravy@domena
15:38 postfix/qmgr[23845] 672282A40BD: from=[odesilatel], size= 398358, nrcpt=1 (quete active)
-----
15:59 postfix/local[26735] 672282A40BD: to=lokalni prijemce, orig_to=prijemce mail, relay=local, delay=1253, delays=2/0/0/1251, dsn=4.3.0, status=deferred (temporary failure. Command output: maildrop: Timeout quota exceeded.)
-----
16:22 postfix/qmgr[23845] 672282A40BD: from=[odesilatel], size= 398358, nrcpt=1 (quete active)
16:22 postfix/local[27098] 672282A40BD: to=lokalni prijemce, orig_to=prijemce mail, relay=local, delay=2615, delays=2614/0.05/0/0.76, dsn=2.0.0, status=sent (delivered to command: /usr/bin/maildrop)

Můžete mě s tím helfnout? Nevím proč to tak dlouho čeka a nechapu tu hlašku 15:59, proč to nedoručil??

Odpovědi

[Piki_]

A je to na vsechny emaily ? Napadlo me jestli neni na druhe strane Postgrey a ty mas u sebe nastaveno, aby to postfix zkousel znova za tak dlouho

[Kall Ell]

Ne, je to jen u nekterych mailu. Ale je to problem, protoze se jedna o spedici a kdyz dojde mail na dopravu s hodinovym spozdenim, tak uz na to nikdo nemusi odpovidat, protoze je to pase.

[Jirka]

A neni problem v pocitaci klienta? Zkusil bych si na jinem PC zalozit ten problemovy ucet a odeslat postu. Take bych se podival na zdrojovy text zpozdene zpravy, neni tam neco spatne?

[Kall Ell]

v klientovy problem nebude, lokalne poslany mail dorazi hned, a klient se pripojuje do schranky pres imap. Kdyz ale mail ve schrance neni, tak to prece klient neovlivni. Me nejde do hlavy, jak je mozne ze server ten mail prijme 15:38 a do schranky klienta ho do doruci v 16:22 musi byt problem nekde na tom serveru. Na co tak dlouho ceka? z logu to nejde poznat. snazil se ji dorucit 15:59 s nejakou chybou ktere nerozumim a pak ji dorucil uspesne 16:22.

[Heron]

Mail může přijít klidně za týden a bude to v pořádku (výše zmíněný graylisting, pomalé MTA). Email není instant messaging, email ani nijak nezaručuje přijetí zprávy. Na něco tak důležitého jako je spedice je to krajně nevhodné řešení.

[Kall Ell]

Co myslis pomalim MTA? Ten server je novy. Bezi na Intelu core 2 duo s 2GB Ram. mimo mail server tam bezi samba. zatizeni serveru je minimalni. jak pisu vys, ten mail na server dorazil 15:38 ale postfix ho dorucil do schranky uzivatele 16:22, to znamena, ze to nejakych 44 minut nekde na tom serveru vyselo. Ale nedokazu zjistit kde. Nejsem profik, na linux, zakazni me k tomu vice mene donutil. I tak jsem ho upozornoval na to ze muzou byt problemy, ale tohle se prece musi dat vyresit ne? kdyz poslu mail lokalne tak ho postfix doruci okamzite.

[Heron]

Já jsem to myslel obecně.

No těch 44 minut to zřejmně trucovalo v amavisu. Proč, to nevím. Zkus tam nechat pouze postfix a dovecot bez těch anti-spam/virus blbostí (pro lokální doručení to přes ně asi neprotéká). Pokud to pojede normálně přidej tam ty filtry. A uvidíš, kde to začne dělat neplechu.

[Kall Ell]

co znamena chyba status=deferred (temporary failure. Command output: maildrop: Timeout quota exceeded.)?? kdyz se ho snazil dorucit v 15:59(i to bylo sice pozde) tak to zkoncilo s touto chybou, ale ani google me s ni neporadil

[oron]

nema user nahodou uz plnu schranku a postfix to preto nemoze dorucit
a ked user nieco zmaze tak sa to doruci ...

[Kall Ell]

to urcite ne, schranky jsem neomezoval. Vsechny maily zustavaji na serveru, prohlizi si je pres imap. jen tri lidi kteri sedi mimo kancelar si je stahuji pres pop3.

[Marian]

predsa len by som zvysil default limity na velkost malilu a schranky... aspon vylucis tuto moznost...

[hellowiin]

největší zdržování mají na starosti různé testy (samozřejmě pokud tam není greylist, který je na zdržování založen). náročná je antivirová kontrola, antispam, dost se to může zaseknout na rbl testech (dotazy do dns, pokud neodpoví, tak mail projde, ale timenout na "neodpověď" může být dlouhý). z toho logu není moc patrno, co všechno tam probíhá a na čem se to zdrželo.

[linuxik]

Ahoj,

to vypada na problem s maildropem, mas v nem nastavene nejake filtrovani zprav, pripadne muzou si uzivatele samy vytvaret filtry? Pokud jsem se dobre dival tak to znamena, ze maildrop nestihnul zpravu dorucit do 5 minut.

[Kall Ell]

 s poskytovatelem jsem tuhle situaci resil a zjistili jsme nasledujici. Nastavene to mame tak, ze je domena smerovana na mailserver naseho poskytovatele. Ten ma nastaveny forward pro nase dve domeny na nas mailserver. Vsechny zpravy podroby antispamovou kontrolou a pak je forwarduje. Jestli je ale zprava abc@nasedomena.cz a uzivatel abc neexistuje, pak nas server tento mail vrati serveru poskytovatele. Ten to zkousi posilat po 15 minutach znovu coz zatezuje jednak linku i server neustalim odmitanim. Lze v postfixu nastavit aby tyto maily nevracel ale zahodil? Techto mailu nam chodi denne stovky. Jinak greylist ma u nasi domeny nastaveny nas poskytovatel.

[linuxik]

Urcite to jde, ale, tohle udelat nemuzes. Tim by totiz dochazelo ke ztrate mailu v pripade ze se odesilatel prepise ve jmene prijemce. Zkontroluj si jestli tvuj mailserver odpovida na neexistujici mailbox chybou 550 (neco jako: 550 5.1.1 User unknown (in reply to RCPT TO command) ) a jestli jo tak  nakopni tveho poskytovatele do zadku at si da mailserver dohromady nebo pozadej o zmenu MX zaznamu v DNS a nech si maily posilat primo na tvuj server.

 

 

 

[Filip Jirsák]

Tohle má v době spamu a virů bohužel jediné řešení, které je v souladu s RFC – nějakým způsobem poskytnout/poskytovat ISP seznam platných schránek (a nebo si od něj nechat doručovat e-maily rovnou přes LMTP, což je skoro ekvivalentní). Pokud takový seznam ISP nemá musí spoléhat na chybu 550 od klientova serveru – a v okamžiku, když se tuhle chybu dozví, zpracovává už e-mail z fronty a nemá otevřené spojení s původním klientem. Tudíž sám nemůže odpovědět chybou 550, ale měl by (podle RFC) odeslat původnímu odesílateli chybovou zprávu. Jenomže v případě spamu či virů (které nejčastěji budou posílat e-mail na neplatnou adresu) je původní odesílatel zfalšovaný – buď nějaký vygenerovaný e-mail (čímž se „jenom“ zbytečně zatíží e-mailové systémy), nebo skutečná schránka, takže nějakému chudákovi přijde zpráva o tom, že e-mail (který vůbec neodesílal), nebyl doručen. Než to, raději porušovat RFC a chybové zprávy neodesílat.