Navratovy kod 552 je sice hezka vec, ale cela vec je bohuzel ponekud slozitejsi.
Nemam sice tuseni o tom, jak je prijem mailu implementovany na serveru Centrum, ale da se predpokladat, ze prijem pomoci SMTP obstarava nejaky program, ktery maily pouze ulozi do fronty. Odtud se pak presouvaji do databaze - a teprve pri tomto presunu se zjisti, ze uzivateli pretekla quota. Co s tim? Neni jina moznost, nez poslat mail s chybou, protoze spojeni, po kterem by byvalo slo vratit status 552, jiz davno neexistuje. To je vsak pouze implementacni detail, mozna to tak opravdu je, mozna neni, na tom prilis nesejde. Existuji totiz minimalne dva duvody, proc odpoved 552 nic neresi...
Za prve, co kdyz dany mail prichazi vice adresatum na danem serveru? Nejprve prijde seznam RCPT-TO, tedy adresy, na ktere se ma dopis dorucit. Pritom jeste neni mozne detekovat preteceni quoty, nebot neni znamo, jak dlouhy mail bude. Pak se precte vlastni mail a muze dojit k tomu, ze nekterym adresatum se do schranky vejde, ale jednomu ne. Jak nyni vratit chybovou hodnotu? SMTP protokol bohuzel nedovoluje v tomto miste specifikovat chybu pouze pro nektere adresaty. Takze neni jina moznost, nez poslat nazpet automaticky generovany mail s popisem chyby.
A za druhe, coz je jeste zavaznejsi, odpoved 552 vubec nepomuze! Jestlize server vrati "552 quota exceeded", SMTP agent (klient), ktery se snazil mail na dany server poslat, stejne vygeneruje chybovy mail na adresu odesilatele puvodni zpravy. Do tohoto mailu napise, ze obdrzel chybovou odpoved 552. Takze mail odesilateli je poslan stejne, pouze je anglicky a odeslany z jineho mista.
Takze kritizovat je sice pekne, ale bylo by dobre si navrhy dobre promyslet a predstavit si vsechny nasledky. Ono totiz provozovat freemailovy server je mnohem slozitejsi, nez by se na prvni pohled mohlo zdat... ;-)
Nikoli. MTA nemá povinnost hlásit nedoručitelnou poštu už při přijímání pošty a spousta populárních MTA (mám dojem, že např. qmail) se tak nechová. Nehledě na to, že netuším, jak by to změnilo situaci. Pokud by ochrana před chybovými maily byla zabezpečena jen při odesílání, musel by odesílač předpokládat, že vždy hovoří s cílovým MTA, což nemusí být pravda - na cestě může být zcela legálně relay a potom chybové hlášky dostanete pouze ve formě mailu, zkrátka proto, že tertia non datur.
Naopak, u qmailu se da e-mail zpracovavat jeste v dobe, kdy je otevrene spojeni (takze se da vratit chyba typu "pretekla quota" nebo "uzivatel neexistuje").
Prominte, ze to reknu tak ostre, ale kdyz tomu nerozumite, tak do toho nemluvte. qmail pri vstupu mail pouze ulozi do fronty a indikuje uspech. Jakekoliv zkoumani, komu mail dorucit, a jestli treba nepretekly quoty, nasleduje nekdy pozdeji.
Tak jsem to zkousel a mate pravdu, omlouvam se za desinformaci.
Opravdu to vrati 250 (queued) a mail o chybe se vygeneruje extra.
Myslel jsem si, ze to tak je, protoze mi na jednom serveru, kde je qmail pripojeny k databazi, staci vratit z toho programu, co to uklada do db navratovy kod 100 a na stderr vysypat chybovou hlasku a qmail uz se sam postara o odeslani hlaseni o chybe (na rozdil od sendmailu, kde se mi toto nepodarilo zajistit).
to vse je sice hezke - ovsem mailer centra se nechova v techto pripadech standardne: zpravu s chybou sice posle na odesilatele, jez je uveden v MAIL FROM v obalce, nicmene jako odesilatele neda (jak je standardem) sebe (tj. MAILER-DAEMON, ci postmaster) ale uzivatele, kteremu quota dosla.
kdyby se tedy choval i on standardne, k zacykleni by nemohlo dojit i v pripade, ze pandora spatne vyplnovala MAIL FROM v obalce.
to je ale omyl: pokud by vratil chybovy kod 5xx, tak i v pripade, ze mail pujde pres relay, bude vse v poradku - neuspel totiz MAILER-DAEMON nebo postmaster na relayi a zprava o nedorucitelnosti se sice dopravi zpet na adresu konference, ale pandora tyto zpravy zpracovava a do konferenci se tyto nikdy nedostanou.
problem je tedy i na strane centra, ktere by melo tyto chybove maily odesilat od sveho MAILER-DAEMONA a nikoliv od uzivatele, se kterym ma problemy nebo okamzite vracet kod 5xx (v pripade, ze je to mozne).
chyba je samozrejme i na strane pandory a jejimu autorovi to taky bude receno, az bude dostupny.
nicmene stale nechapu postup centra, ktery se zcela vymyka standardnimu chovani: pokud uzivateli dojde misto, mel by jejich mailer daemon vyhodit kod 552 ci 4xx dle RFC821 a ne odeslat mail odesilateli s tim, ze tomuto uzivateli dosla quota. kdyby se tedy centrum chovalo podle standardu, nedoslo by k temto problemum.
Michal Vitecek
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
