Re: [rlug] Linux Install Fest 2013
On 26 September 2013 23:03, Petru Ratiu wrote: > Inauguram de-acu incolo expresia "tipic rosedu" pentru ambele nameservere > declarate pe acelasi IP? > Mai trist e faptul că ns-ul secundar e down de probabil un an :P Actually, chiar recent am făcut zonă slave pe dns.he.net, doar că nu le-am publicat ca ns-uri oficiale. Evident, regret. > Pe vremea mea radeau copiii la gradinita de tine doar daca le aveai in > aceeasi clasa C... > > AJ, cand revine curentul in Poli cauta-ma sa vedem cum iti setez un slave > pe ns1.lug.ro. > > > On Thu, Sep 26, 2013 at 10:10 PM, Andrei Pascal wrote: > >> "Tipic RoEDU", pentru cine știe... >> >> >> On Thu, Sep 26, 2013 at 9:00 PM, Alexandru Juncu > >wrote: >> >> > On 26 September 2013 20:57, Mihai Maruseac >> > wrote: >> > > 2013/9/26 Petre Mihail : >> > >> Iupii: >> > >> "Server not found" >> > >> May i mumble...? >> > > >> > > UPB și site reliability. >> > >> > RoEduNet (actually) ftw! >> > ___ >> > RLUG mailing list >> > RLUG@lists.lug.ro >> > http://lists.lug.ro/mailman/listinfo/rlug >> > >> >> >> >> -- >> Ave >> http://flying.prwave.ro >> ___ >> RLUG mailing list >> RLUG@lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug >> > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Linux Install Fest 2013
Inauguram de-acu incolo expresia "tipic rosedu" pentru ambele nameservere declarate pe acelasi IP? Pe vremea mea radeau copiii la gradinita de tine doar daca le aveai in aceeasi clasa C... AJ, cand revine curentul in Poli cauta-ma sa vedem cum iti setez un slave pe ns1.lug.ro. On Thu, Sep 26, 2013 at 10:10 PM, Andrei Pascal wrote: > "Tipic RoEDU", pentru cine știe... > > > On Thu, Sep 26, 2013 at 9:00 PM, Alexandru Juncu >wrote: > > > On 26 September 2013 20:57, Mihai Maruseac > > wrote: > > > 2013/9/26 Petre Mihail : > > >> Iupii: > > >> "Server not found" > > >> May i mumble...? > > > > > > UPB și site reliability. > > > > RoEduNet (actually) ftw! > > ___ > > RLUG mailing list > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug > > > > > > -- > Ave > http://flying.prwave.ro > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Linux Install Fest 2013
"Tipic RoEDU", pentru cine știe... On Thu, Sep 26, 2013 at 9:00 PM, Alexandru Juncu wrote: > On 26 September 2013 20:57, Mihai Maruseac > wrote: > > 2013/9/26 Petre Mihail : > >> Iupii: > >> "Server not found" > >> May i mumble...? > > > > UPB și site reliability. > > RoEduNet (actually) ftw! > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > -- Ave http://flying.prwave.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Linux Install Fest 2013
On 26 September 2013 20:57, Mihai Maruseac wrote: > 2013/9/26 Petre Mihail : >> Iupii: >> "Server not found" >> May i mumble...? > > UPB și site reliability. RoEduNet (actually) ftw! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Linux Install Fest 2013
2013/9/26 Petre Mihail : > Iupii: > "Server not found" > May i mumble...? UPB și site reliability. -- MM "All we have to decide is what we do with the time that is given to us" ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Linux Install Fest 2013
Iupii: "Server not found" May i mumble...? 2013/9/26 Catalin Vasile > Buna seara, > > Numele meu este Catalin Vasile si anul acesta voi fi unul dintre > coordonatorii evenimentului > Linux Install Fest[1] care va avea loc in cadrul Facultatii de > Automatica si Calculatoare, UPB. > As dori sa invit persoanele doritoare sa ajute bobocii sa depaseasca > diverse probleme privind instalarea distributiilor de Linux Mint, Arch, > Debian, Fedora, openSUSE pe data de 5 octombrie in hol EC. :D > > > Numai bine, > Catalin. > > [1] http://lif.rosedu.org/lif/ > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
> Pai de obicei lumea pune smtp frontend nu doar de dragul de a nu expune > direct in internet exchangeul (sa zicem groupwareul) cit si pentru a > minimiza sau ascunde momentele de indisponibilitate temporara a acelui Side note Nu stiu altii, eu am frontend pentru a nu expune exchange si - important - a rula antivirus si antispam. Aia cu ascunde indisponibilitatea nu prea ma doare, nu este planificat sa nu functioneze exchange-ul pentru 24 de ore ca sa zici ca incepi sa pierzi mailuri. Si nici nu mai sintem in epoca modemuri de 33.6k ca sa transpir ca vai incep dupa aia sa vina mailurile puhoi si se infunda teava. Dar fiecare cu cazul lui particular. Dan ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] Linux Install Fest 2013
Buna seara, Numele meu este Catalin Vasile si anul acesta voi fi unul dintre coordonatorii evenimentului Linux Install Fest[1] care va avea loc in cadrul Facultatii de Automatica si Calculatoare, UPB. As dori sa invit persoanele doritoare sa ajute bobocii sa depaseasca diverse probleme privind instalarea distributiilor de Linux Mint, Arch, Debian, Fedora, openSUSE pe data de 5 octombrie in hol EC. :D Numai bine, Catalin. [1] http://lif.rosedu.org/lif/ ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
> 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). 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. 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". 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. 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. Doar daca intorci 4xx pentru 4xx de la backend, dar atunci ce faci cu 5xx-ul corect de la backend ? (ex virus detected )? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
2013/9/27 Vali Dragnuta : > >> Vezi mai sus, afla de ce si rezolva problema. Daca junghiul de >> exchange da raspuns negativ e *foarte* probabil sa nu accepte mailul, >> atunci de ce l-ar accepta serverul din fata lui? Cel mai simplu >> exemplu ca sa vezi ca in cazul asta, daca nu esti atent, ajungi la >> backscatter: proxy-ul accepta conexiunea de la client, la rcpt to se >> uita in LDAP, accepta mailul, dupa care cand da sa-l livreze la >> destinatie backend-ul trimite 5xx desi userul exista in ldap. Ce crezi >> ca se intampla in cazul asta? :) >> > Pai de obicei lumea pune smtp frontend nu doar de dragul de a nu expune > direct in internet exchangeul (sa zicem groupwareul) cit si pentru a > minimiza sau ascunde momentele de indisponibilitate temporara a acelui > backend. Backendul fiind o platforma tehnica mai complexa este posibil > sa mai aibe momente de indisponibilitate cind mai crapa bazele de > date,resursele sau cind i se mai face upgrade samd. In mare exista 2 tipuri de downtime: planificat si neplanificat. La cel planificat e simplu, configurezi proxy-ul sa tina mesajele in coada pana cand backend-ul e iar pe felie. Cu cel neplanificat e mai complicat ca nu stii cand pica, ce se strica si cum raspunde (sau nu) backend-ul cand e in balarii. In plus, poti pune proxy si pentru alte motive, nu doar de a ascunde chestii. Spre exemplu livrarea catre mai multe backend-uri folosind aceeasi inregistrare MX, filtrari si asa mai departe. > Mie mi se pare un pic iresponsabil sa refuzi mailuri pe care ai putea sa > le accepti bine merci si fara niciun cost suplimentar in resurse (pina > la urma asta face orice mx backup) pina cind backendul devine din nou > disponibil. Iresponsabil sau nu, eu cred ca cele mai multe servere de mail configurate de oameni normali si cu inteligenta medie fac un numar de incercari pe o perioada determinata sa retrimita mailul. Din punctul asta de vedere nu vad beneficiile imediate ale consumului de resurse pe un proxy doar pentru a tine in coada mesaje care pot fi tinute de serverele care trimit. Ma rog, sa zicem ca inteleg sa fac queuing pentru situatii planificate, dar in nici un caz nu am voie sa accept un mesaj pentru un backend care intoarce 5xx. Asta e mai degraba iresponsabilitate :) > Altfel nu faci decit sa exporti problemele din interior spre exterior si > ramii cu singurul beneficiu al frontendului acela ca nu expui > groupwareul la riscuri de securitate din internet. 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? -- Adi Pircalabu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
> Vezi mai sus, afla de ce si rezolva problema. Daca junghiul de > exchange da raspuns negativ e *foarte* probabil sa nu accepte mailul, > atunci de ce l-ar accepta serverul din fata lui? Cel mai simplu > exemplu ca sa vezi ca in cazul asta, daca nu esti atent, ajungi la > backscatter: proxy-ul accepta conexiunea de la client, la rcpt to se > uita in LDAP, accepta mailul, dupa care cand da sa-l livreze la > destinatie backend-ul trimite 5xx desi userul exista in ldap. Ce crezi > ca se intampla in cazul asta? :) > Pai de obicei lumea pune smtp frontend nu doar de dragul de a nu expune direct in internet exchangeul (sa zicem groupwareul) cit si pentru a minimiza sau ascunde momentele de indisponibilitate temporara a acelui backend. Backendul fiind o platforma tehnica mai complexa este posibil sa mai aibe momente de indisponibilitate cind mai crapa bazele de date,resursele sau cind i se mai face upgrade samd. Mie mi se pare un pic iresponsabil sa refuzi mailuri pe care ai putea sa le accepti bine merci si fara niciun cost suplimentar in resurse (pina la urma asta face orice mx backup) pina cind backendul devine din nou disponibil. Altfel nu faci decit sa exporti problemele din interior spre exterior si ramii cu singurul beneficiu al frontendului acela ca nu expui groupwareul la riscuri de securitate din internet. Dar poti face mult mai mult cu cost 0 si cum spuneam, mi se pare un pic iresponsabil sa nu faci asta :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
2013/9/26 Vali Dragnuta : > >> De ce? Pentru verificarea de adresa, dupa rcpt to Postfix tine >> conexiunea deschisa cu clientul, initiaza o conexiune noua la MTA-ul >> pentru care face relay in care verifica raspunsul la rcpt to. Pentru >> ce i-ar trebui sa faca lookup intr-o baza de date cand o face direct >> prin SMTP? A, ca vrei tu sa reduci numarul de conexiuni SMTP la >> serverul din spate e partea a doua, poti lucra cu LDAP si fratii sai, >> dar implicit nu e nevoie. >> > > Pentru ca o verificare sincrona de genul asta nu mi se pare prea > eficienta ca si consum de resurse cind ai un volum mare de mailuri. Exista mecanism de caching care poate fi configurat: http://www.postfix.org/verify.8.html Evident ca solutia cu LDAP la volum mare de mailuri e mai eficienta. Dar pana la urma e important ca decizia de acceptare a mailului sa se ia in functie de ce se intampla pe partea de SMTP. Degeaba faci lookup in baza de date daca Exchange iti intoarce eroare permanenta. > Si ce se intimpla daca smtpul din spate contra caruia verifici e pe > jos ? Sau doar raspunde greu ?De ce sa conditionezi functionarea > proxyului extern de situatia resurselor din backend ? Argumentul cu serverul din backend care-i pe jos nu tine din punctul meu de vedere. De ce sa tina proxy-ul mailuri in coada daca backend-ul e cazut sau lent? Mi se pare mai normal sa trimita 4xx sau 5xx inapoi la client in loc sa accepte mailul si sa-l bage in coada. Raspunde prea greu sistemul din backend? Afla de ce si rezolva problema, nu o muta in alta parte. > Sau daca iti da un raspuns negativ din cauza unei alte erori decit user > inexistent? Vezi mai sus, afla de ce si rezolva problema. Daca junghiul de exchange da raspuns negativ e *foarte* probabil sa nu accepte mailul, atunci de ce l-ar accepta serverul din fata lui? Cel mai simplu exemplu ca sa vezi ca in cazul asta, daca nu esti atent, ajungi la backscatter: proxy-ul accepta conexiunea de la client, la rcpt to se uita in LDAP, accepta mailul, dupa care cand da sa-l livreze la destinatie backend-ul trimite 5xx desi userul exista in ldap. Ce crezi ca se intampla in cazul asta? :) -- Adi Pircalabu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
> De ce? Pentru verificarea de adresa, dupa rcpt to Postfix tine > conexiunea deschisa cu clientul, initiaza o conexiune noua la MTA-ul > pentru care face relay in care verifica raspunsul la rcpt to. Pentru > ce i-ar trebui sa faca lookup intr-o baza de date cand o face direct > prin SMTP? A, ca vrei tu sa reduci numarul de conexiuni SMTP la > serverul din spate e partea a doua, poti lucra cu LDAP si fratii sai, > dar implicit nu e nevoie. > Pentru ca o verificare sincrona de genul asta nu mi se pare prea eficienta ca si consum de resurse cind ai un volum mare de mailuri. Si ce se intimpla daca smtpul din spate contra caruia verifici e pe jos ? Sau doar raspunde greu ?De ce sa conditionezi functionarea proxyului extern de situatia resurselor din backend ? Sau daca iti da un raspuns negativ din cauza unei alte erori decit user inexistent ? Nemaipunind la socoteaca ca exchangeul oricum se va uita el in ldap ca el acolo cred ca-si tine userii... O interogare ldap ar trebui sa fie mult mai rapida chiar si doar pentru ca scoti middle-man din ecuatie. Plus de asta pe resursa ldap de obicei ai mai multa redundanta, si in plus cu asta poti sa mai implementezi la nevoie si smtp authentication si alte lucruri utile care deja sint dificil de implementat doar apelind la smtpul din spate. Pe scurt, folosirea tot a protocolului smtp(intre front proxy si backend smtp) pentru validare sincrona de useri nu mi se pare o solutie eleganta chiar daca altfel poate functiona pina la un punct. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
> > Pai daca pui postfixul doar sa forwardeze mailurile spre un server > > intern trebuie sa ajungi sa faci lookup in altceva (ex ldap). > > De ce? Pentru verificarea de adresa, dupa rcpt to Postfix tine > conexiunea deschisa cu clientul, initiaza o conexiune noua la MTA-ul > pentru care face relay in care verifica raspunsul la rcpt to. Pentru > ce i-ar trebui sa faca lookup intr-o baza de date cand o face direct > prin SMTP? A, ca vrei tu sa reduci numarul de conexiuni SMTP la > serverul din spate e partea a doua, poti lucra cu LDAP si fratii sai, > dar implicit nu e nevoie. Nici eu nu o stiam pe asta :) E interesant, insa sunt niste daca-uri, ca la orice metoda bazata pe cache: se poate manipula durata inregistrarii in cache? Pentru ca tu in exchange mai faci useri, mai stergi... nu stiu cum se comporta in practica. De fapt si frontend-ul de Exchange face tot un soi de cache, foloseste ADAM pentru useri si problema e cam la fel, adica trebuie sa ii zic userului: am facut contul, peste o ora poti primi mailuri... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
On 09/26/2013 10:34 AM, Adi Pircalabu wrote: > De ce? Pentru verificarea de adresa, dupa rcpt to Postfix tine > conexiunea deschisa cu clientul, initiaza o conexiune noua la MTA-ul > pentru care face relay in care verifica raspunsul la rcpt to. Pentru O solutie mai ciobaneasca pt postfix care nu presupune ca mta-ul din spate sa fie tot timpul pe faza Un recipient_access regenerat doar cind e nevoie (cind modifici adrese de mail) faci un programel care citeste prin ldap toate adresele valide din AD In felul asta verificarea e instant De multe spam-uri poti sa scapi daca folosesti un blacklist gen spamhaus, le rejectezi din start deja dupa ip-ul sursa -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
2013/9/26 Eugeniu Patrascu > Exchange trimite NDR doar la senderii interni, asa cum e normal si cum face > fiecare MTA de pe lumea asta. > Pentru conexiunile venite de la alte servere, daca destinatarul nu exista > zice frumos : 55X Recipient could not be found. > Corect, nu Exchange face backscatter, ci qmail, inițial am scris „sistemul”, da' am vrut să strecor și icsceingi cu E mare, că m-a amuzat cum omu' cu problema scrie Exchange cu e mic și qmail cu majusculă! :)) În orice caz, soluția pentru combinația asta (pe care am administrat-o și io câțiva ani) cred că a rămas non-trivială, cu patch-uit qmail și exportat adresele de mail din AD până local pe serverul cu qmail. Dezactivarea NDR-urilor pe qmail e un fel de împușcat în picior, mai ales dacă tot acest qmail livrează și mailurile outbound. Alternativ se poate înlocui qmail cu altceva, ori și mai bine qmail+Exchange cu altceva ce le face pe toate mai bine, mai ieftin, mai uscat... De exemplu, http://www.axigen.com dacă ne place suportul în română. :D ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
2013/9/26 Vali Dragnuta : > > On Thu, 2013-09-26 at 17:14 +1000, Adi Pircalabu wrote: >> 2013/9/26 Vali Dragnuta : >> > >> > Presupun ca cu altceva era mai simplu sa faca un lookup de conturi >> > valide in (spre exemplu) ldap si sa respinga mesajele chiar in timpul >> > tranzactiei initiale de livrare - nu ulterior sub forma de NDR distinct. >> >> In Postfix exista suport pentru verificarea adresei destinatie de >> multa vreme fara artificii suplimentare gen LDAP, vezi >> reject_unverified_recipient >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html >> > > Pai daca pui postfixul doar sa forwardeze mailurile spre un server > intern trebuie sa ajungi sa faci lookup in altceva (ex ldap). De ce? Pentru verificarea de adresa, dupa rcpt to Postfix tine conexiunea deschisa cu clientul, initiaza o conexiune noua la MTA-ul pentru care face relay in care verifica raspunsul la rcpt to. Pentru ce i-ar trebui sa faca lookup intr-o baza de date cand o face direct prin SMTP? A, ca vrei tu sa reduci numarul de conexiuni SMTP la serverul din spate e partea a doua, poti lucra cu LDAP si fratii sai, dar implicit nu e nevoie. -- Adi Pircalabu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
-- Mihai Bădici http://mihai.badici.ro On Thursday 26 September 2013 10:10:57 Vali Dragnuta wrote: > > Da, si asta e problema in sine in cazul in care ai un proxy in fata > > Exchange-ului care nu stie sa faca verificare de adresa a > > destinatarului cand primeste conexiunea de la client, cum e cazul > > qmail-ului chior. Raspunsul 55x genereaza un bounce trimis de proxy la > > o adresa nevinovata si asta e exact backscatter. > > Cred ca exchangeul ala nu merge fara un ldap/AD si in teorie cred ca ai > putea sa faci lookup si din proxy pt conturi valide. In teorie se poate dar in practica e cam complicat ( ar trebui de exemplu ca acel qmail, care e de regula in dmz sau in internet, sa aiba acces la domain controllere, ceea ce e o mica gaurica in firewall, plus ceva nat de trecut, iar bind-ul prca mergea doar autentificat, deci trebuie si un user de domeniu) Banuiesc ca oricum qmail-ul trimite toate mailurile la exchange, si daca il setezi sa nu trimita NDR , asta e, eu zic ca e rezonabil. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
On Thu, 2013-09-26 at 17:14 +1000, Adi Pircalabu wrote: > 2013/9/26 Vali Dragnuta : > > > > Presupun ca cu altceva era mai simplu sa faca un lookup de conturi > > valide in (spre exemplu) ldap si sa respinga mesajele chiar in timpul > > tranzactiei initiale de livrare - nu ulterior sub forma de NDR distinct. > > In Postfix exista suport pentru verificarea adresei destinatie de > multa vreme fara artificii suplimentare gen LDAP, vezi > reject_unverified_recipient > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > Pai daca pui postfixul doar sa forwardeze mailurile spre un server intern trebuie sa ajungi sa faci lookup in altceva (ex ldap). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
2013/9/26 Vali Dragnuta : > > Presupun ca cu altceva era mai simplu sa faca un lookup de conturi > valide in (spre exemplu) ldap si sa respinga mesajele chiar in timpul > tranzactiei initiale de livrare - nu ulterior sub forma de NDR distinct. In Postfix exista suport pentru verificarea adresei destinatie de multa vreme fara artificii suplimentare gen LDAP, vezi reject_unverified_recipient http://www.postfix.org/ADDRESS_VERIFICATION_README.html -- Adi Pircalabu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
> Da, si asta e problema in sine in cazul in care ai un proxy in fata > Exchange-ului care nu stie sa faca verificare de adresa a > destinatarului cand primeste conexiunea de la client, cum e cazul > qmail-ului chior. Raspunsul 55x genereaza un bounce trimis de proxy la > o adresa nevinovata si asta e exact backscatter. Cred ca exchangeul ala nu merge fara un ldap/AD si in teorie cred ca ai putea sa faci lookup si din proxy pt conturi valide. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
2013/9/26 Eugeniu Patrascu : > Exchange trimite NDR doar la senderii interni, asa cum e normal si cum face > fiecare MTA de pe lumea asta. > Pentru conexiunile venite de la alte servere, daca destinatarul nu exista > zice frumos : 55X Recipient could not be found. Da, si asta e problema in sine in cazul in care ai un proxy in fata Exchange-ului care nu stie sa faca verificare de adresa a destinatarului cand primeste conexiunea de la client, cum e cazul qmail-ului chior. Raspunsul 55x genereaza un bounce trimis de proxy la o adresa nevinovata si asta e exact backscatter. @Catalin Vasilescu: cum ai configurat qmail la momentul asta ca sa reduci spamul? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
-- Mihai Bădici http://mihai.badici.ro On Thursday 26 September 2013 10:00:33 Eugeniu Patrascu wrote: > Exchange trimite NDR doar la senderii interni, asa cum e normal si cum face > fiecare MTA de pe lumea asta. > Pentru conexiunile venite de la alte servere, daca destinatarul nu exista > zice frumos : 55X Recipient could not be found. Cred ca depinde de exchange, stiu ca de-a lungul timpului am avut probleme la servere mai vechi. Dar se poate dezactiva. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
On Thu, 2013-09-26 at 09:57 +0300, Mihai Badici wrote: > On Thursday 26 September 2013 09:54:35 Mișu Moldovan wrote: > > 2013/9/26 Catalin Vasilescu > > > > > Qmailul nu le filtreaza si ajung in exchange. > > > > Care ce face cu spamurile astea? > > > > În plus, am o bănuială că qmailu' tău nu știe care-s adresele de mail > > valide din domeniile pentru care acceptă mail, prin urmare Exchange-ul face > > backscatter la adresele invalide de destinatari din propriile domenii. > Pai asta era valabil si daca nu era qmail-ul. > Dar se poate dezactiva NDR-ul din exchange. Presupun ca cu altceva era mai simplu sa faca un lookup de conturi valide in (spre exemplu) ldap si sa respinga mesajele chiar in timpul tranzactiei initiale de livrare - nu ulterior sub forma de NDR distinct. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
Am dezactivat NDR pentru adresele externe. Spam-urile sunt livrate in inbox-ul user-ilor. --- Catalin Vasilescu From: Mihai Badici To: Romanian Linux Users Group Sent: Thursday, September 26, 2013 9:57 AM Subject: Re: [rlug] Block "Joe Jobs" Qmail On Thursday 26 September 2013 09:54:35 Mișu Moldovan wrote: > 2013/9/26 Catalin Vasilescu > > > Qmailul nu le filtreaza si ajung in exchange. > > Care ce face cu spamurile astea? > > În plus, am o bănuială că qmailu' tău nu știe care-s adresele de mail > valide din domeniile pentru care acceptă mail, prin urmare Exchange-ul face > backscatter la adresele invalide de destinatari din propriile domenii. Pai asta era valabil si daca nu era qmail-ul. Dar se poate dezactiva NDR-ul din exchange. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block "Joe Jobs" Qmail
Exchange trimite NDR doar la senderii interni, asa cum e normal si cum face fiecare MTA de pe lumea asta. Pentru conexiunile venite de la alte servere, daca destinatarul nu exista zice frumos : 55X Recipient could not be found. 2013/9/26 Mihai Badici > > On Thursday 26 September 2013 09:54:35 Mișu Moldovan wrote: > > 2013/9/26 Catalin Vasilescu > > > > > Qmailul nu le filtreaza si ajung in exchange. > > > > Care ce face cu spamurile astea? > > > > În plus, am o bănuială că qmailu' tău nu știe care-s adresele de mail > > valide din domeniile pentru care acceptă mail, prin urmare Exchange-ul > face > > backscatter la adresele invalide de destinatari din propriile domenii. > Pai asta era valabil si daca nu era qmail-ul. > Dar se poate dezactiva NDR-ul din exchange. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
