2013/9/27 Vali Dragnuta <[email protected]>: > >> Punctual, cum rezolvi tu problema cu backend-ul care a luat-o razna si >> intoarce 5xx la toate conexiunile? Ce crezi ca trebuie sa faca >> proxy-ul in situatia asta? Sa accepte mailul sau nu? >> > Asta e o alta problema a solutiei "use smtp as identity verification" : > nu mai poti deosebi situatia in care iti da 5xx din motive corecte (ex > content filter, a gasit un virus etc) sau din motiv de problema de > configurare (ex administratoru' loveste si blacklisteaza *@*.com) sau > din motive accidentale (ex userul are quota pe groupware si si-a umplut > quota rezervata).
Poate vii tu cu o solutie de a extinde protocolul SMTP asa incat sa poti aprecia cand e bine sa tii un mesaj in coada daca backend-ul raspunde 5xx, ca mie nu-mi da prin cap :) Pentru oricare din motivele date de tine backend-ul, dupa parerea mea, raspunde exact cum trebuie sa raspunda iar senderul - cel real! - trebuie sa stie de indisponibilitatea contului respectiv, macar si pentru motivul banal de a-i da un telefon destinatarului sa-i transmita ca si-a depasit quota si nu-i mai poate trimite bancuri in format docx. > Exceptind cazul cu virusii eu mi-as dori in celelalte cazuri sa pastrez > mesajul primit ca sa-l pot livra mai tirziu cind problema din backend > dispare. Eu nu cred ca e o idee buna, vezi mai sus. Problema din backend poate disparea mai repede sau mai greu, sa tii mailurile in coada proxy-ului pana cand se trezeste cineva sa rezolve problema nu mi se pare prea eficient, nu faci decat sa ascunzi problema. Orice disfunctionalitate trebuie descoperita cat mai repede ca sa fie remediata cat mai repede. > Scopul unui server de mail e sa poata primi cit mai multe > mesaje *legitime* nu sa refuze din principiu mesaje pe motivul "daca > sefu' de deasupra are o problema imi bag si eu piciorul si nu mai > lucrez". Scopul e sa asiguri o metoda de transport cat mai fiabila si cu cat mai putini virusi, spam sau backscatter. Singura certitudine o ai in dialogul SMTP, in rest e multa munca degeaba, overengineering inutil. > Tot legat de ce ai spus tu cu serverele configurate de oameni normai > care fac retry mai ai si aici o problema : pe de-o parte ca > nu stii exact cit de mult vor face retry comparativ cu perioada ta de > downtime... sau cu perioada pina cind iti dai seama ca ai o problema - > in caz ca nu este imediat aparenta. Daca trece mult timp (cat?) fara sa-ti dai seama ca ai o problema esti suficient de incompetent incat sa lasi pe altul in loc. Si oricum in cazul asta e de preferat sa primesti un telefon de la sefu' sau un partener nervos ca primeste 5xx de la tine in loc sa tii mailurile 2-3 zile in coada, pana trece weekend-ul. Eu unul nu vad nici un fel de problema sa trimit bounce-uri inapoi la senderi, cata vreme bounce-urile alea ajung *unde trebuie*. > Pe de alta parte, daca tu te > hotarasti sa copiezi statusul de la backend si pe frontend, atunci in > cazul in care backendul are o problema de configurare si intoarce 5xx > iar tu il mirrorezi vei inchide posibilitatea de a avea retry mai > tirziu. Da, nici o problema, repar configurarea si ii dau drumul iar. E preferabil in loc sa fiu sursa de backscatter. Cum ai zis chiar tu: cum apreciez daca un raspuns 5xx e "legitim" sau nu? > Doar daca intorci 4xx pentru 4xx de la backend, dar atunci ce > faci cu 5xx-ul corect de la backend ? (ex virus detected )? Daca mailul trece de antivirusul de pe proxy, dar e prins de antivirusul de pe backend exista o solutie simpla: 250 OK si discard pe backend. Altfel sistemul devine sursa de backscatter. Daca ai acceptat mailul pe proxy e musai sa-l accepti pe backend. -- Adi Pircalabu _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
