Koszi az "oktatast" de 1995 ota uzemeltetek mail szervereket, sok mindent lattam mar, nyilvan tisztaban vagyok a SAV elonyeivel es hatranyaival is :) De ahogy pont az altalad is idezett spam wikia oldal is irja, vannak elonyei (is ...). Tehat eleve nem _teljesen_ balfasz es eszement (ez ugye akkor lenne, ha nem lenne elonye ...). Ettol persze tokeletesen igazad van, hogy hatranya is van, nem is keves. Eppen ezert nem is hasznalunk klasszikus SAV-ot (csak nem akartam meg nagyobb kisregenyt irni, de ugy latom szukseg lesz ra megis, tehat megteszem mindjart, turelem). De altalanossagban is igaz, hogy tokeletes policy-k nincsenek, olyat nem fogsz talalni ami hatekony, de nem rendelkezik hatranyokkal. Az persze kerdeses, hogy mennyi hatranya van ... Es milyen a hatekonysaga. Ez nyilvan merlegeles kerdese. Eleve az az elved, hogy a SAV elbaszott/eszement, mutatja, hogy nem igazan elemzo modon allsz hozza a kerdeshez. Minden megoldasnak akadhat letjogosultsaga, nincs abszolute kiraly es abszolute eszement policy se igazan, helyzete valogatja. Ez persze az altalanos rizsa volt, nem is untatlak tovabb vele. Illetve egy adott elv (itt a SAV) is implementalhato kulonbozo modon, ami kulonbozo hatekonysagokhoz vezet, de a hatranyok mennyisege is csokkentheto. Az egyszeruseg kedveert hivjuk pl tudomisen "SAV classic"-nak, azt amit altalaban a legtobb SAV implementacio csinal. A SAV csak egy elv, azt valahogy implementalni kell. Ennek alapjan legyen a "SAV classic" az, amikor a fogado mail szerver a sender-t "validalni" akarja, ezert indit egy SMTP tranzakciot a specifikalt sender fele mint rcpt, es nezi az eredmenyt. Na, ilyet nem csinalunk, pont ezek hatranyai miatt. Ezek kozott van ugye az is, hogy eleve a SAV celjabol inditott SMTP tranzakciokat a kerdeses rcpt domain MX szervere megelheti egyfajta "tamadasnak" is, foleg, ha csak behazudtak ugymond a feladot, es nem is tole szarmazik a mail, foleg ha mindenfele random generalt localpart-ot tesznek a valoban letezo sender domain ele.
Az, hogy csak SAV-nak hivom amit csinalunk, annak oka az, hogy ugyfelnek meno valaszokban teljesen felesleges ilyen dolgokat irni mint amit itt fogok. Reszben azert mert total nem erdekli, reszben lehet ennyire at se latja, ezert a HD fele nyilvan en azt szoktam irni, hogy az ugyfelnek a SAV-rol beszeljenek, es pont.
Tekintve, hogy az altalunk alkalmazott megoldas custom megoldas, talan megerted, hogy nem adok teljes leirast, nem teszem fel a github-ra public repo-ba stb. Attol a lenyeget persze vazolhatom, ha mar szukseg van ra. A belsoleg fejlesztett megoldas (felve megjegyzem, hogy en fejlesztettem, tudom, mindjart jon az intelmed, hogy lam programozni sem tudok, ehhez sem ertek ... es kezdheted az ujabb flame-et ...) lenyege a log analizisen alapul. Ez kvazi-real-time zajlik (ezzel parhuzamosan egy logging [postfix] policy daemon is van amugy). Valojaban "nem tudjuk", hogy "mukodik-e a sender" (azaz fogadna is ...), mivel nem ellenorizzuk azt egy kulon erre a celra "dedikalt" SMTP tranzakcioval, ahogy a "SAV classic" vegezne ezt. Ezert nem is lesz olyan hatekony, viszont elminalhato, az a hatrany pl, amit fentebb kifejtettem. Persze sok elonyet is elveszti ezzel, ez igaz, dehat altalaban az eremnek ket oldala van. Amit csinalunk, az voltakeppen annyi, hogy sok mail-re az emberek ugye valaszolnak is. Tehat lesz olyan SMTP tranzkacio pl, amit nem dedikaltan a sender verifikalasara inditottunk, hanem "amugy is lenne", de felhasznalhato - ha mar ott van -, hogy ellenorizzuk, letezik-e olyan celcim (ami ellenkezo mail iranynal pl a felado lenne). Igen, mondhatod, hogy ez baromsag, mivel ugye egyaltalan nem biztos, hogy lesz ilyen tranzkacio, illetve, ha van is, az _kesobb_ van esetleg mint a bejovo mail. A lenyege ennek az egesznek alapvetoen nem a tilas. Ebbol statiszika keszul allandoan es automatikusan, ami allandoan frissul. Pl, csak hogy vazoljam a konkret peldat, amit emlitettem: ebbol derult ki a t-com-os adathalaszat esete is a dot.com-al, megjelent a statisztikaban mint "gyanus" elem. Ugyanis par ugyfelunk valaszolt ra, es nem ment el a mail, illetve kepzodott volna NDR is, ami szinten nem ment el (mielott kozbeszolsz: IGEN, nem szep dolog NDR-t kuldeni, az ember pl backscatterer listara kerulhet, illene nem elfogadni azt mar MX szerveren amit aztan nem tudunk kezelni kesobb ... dehat ugye semmi sem tokeletes, pl vannak ugyfeleink akik ugy kernek inbound mail relay-t, hogy nincs valid rcpt listank, igy nem tudjuk, mit fog az majd elfogadni ... stb stb stb). Tehat ez az elv eleve tokeletlen (tudom-tudom: 'eszement'), es kevesbe hatekony, de hidd el meglepoen gyakran vezet erdekes eredmenyekre, annak ellenere, hogy ez tehat egy "passziv" statisztika (log elemzesbol) es nem egy valodi aktiv megoldas (mint a "SAV classic"). Ennek ellenere nevezhetjuk sender address verification-nak vegulis, mert a celja kb ez, csak epp statiszikai alapokon, "passziv" modon. Meg nyilvan ennek problemai miatt rengeteg dolog "atcsuszik" rajta termeszetesen. Viszont erdekes modon eleg gyakran vezet eredmenyre. Node, ami a lenyeg, ebbol a statisztikabol _SEM_ tortenik tiltas. Az elemzes javaslatokat tesz, ami akkor kerul elbiralasra (manualis uton) ha megut egy szintet, hogy "erdemes" vele foglalkozni, mert a logok tanulsaga szerint a sender mint rcpt nem mukodott, ugyanakkor ennek kizarasa nagy mennyisegu mail-tol elminalna minket a jovoben. Amirol persze peldak is vannak, a content filter megfelelo spam score altamasztasaval, meg par alap adattal.
Amugy legtobb policy-nk elemzes alapjan megy, nem feltetlen "kobe vesett" ha a == b akkor c alapu automatizmus. Persze kivetelek is vannak (pl RBL-ek), nem *minden* policy-nk ilyen azert, en arra torekedtem az evek soran, hogy lehetoleg abba az iranyba mozduljunk el, ami baratsagosabb, kevesebb lehetseges hibabejelenteshez vezet, stb stb (ezzel ellentetben ugye egy /15 blokkolasa IP szinten nem epp ilyen ...). Tudom, velem van a baj, mit erdekel ez engem ... Bocs, bennem van a hiba. A jelen problemara visszaterve (vegre ide is eljutottunk!), valojaban meglepoen keves letiltas kepzodott nalunk a nevezett problema miatt. Ha ez automatikus ("SAV classic") lett volna, akkor nyilvan ennek tobbszorose. Konkretan kevesebb mint fel tucat domain kerult blokkolasra. Persze, azt nehez megmondani hogy "mennyibol", hiszen azt nem tudhatjuk, hogy ki tiltott minket es mifele sender domain-ekkel nyomultak. Ja, az meg kimaradt, hogy extrem esetektol eltekintve (ez is statisztikabol derul ki), altalaban ennel a megoldasnal legalabbis nem lovunk a konkret local-part@domain-re csak a domain reszere. Foleg az ellenorzes passziv jellege miatt nehez lenne maskepp. Itt az ellenorzes fokepp arra iranyul, hogy egyaltalan _BARMIT_ fogad-e (pl mar csak az, hogy smtp kapcsolatot fogad-e ...), mint mail szerver funkcional-e a sender MX-sze (nyilvan ha nincs MX-sze, akkor az A rekord ... mert ugye rfc szerint igy kell ... ennek ellenere talan a T csinalja azt - HA jol emlekszem, ha nem bocsanat ... -, hogy nem fogad mail-eket olyan sender domain-rol aminek nincs MX rekordja, pedig rfc szerint lehet meg legitim, mivel ugye MX rekord hianyaban az A-t kene nezni ... na en ezt neveznem pl eszementnek ...)
A felvetesed, hogy nem nezel ki belolem annyi eszt (koszonom szepen), hogy tudom, mi legyen 15db MX-nel: pedig rosszul teszed, mert ez ellenorzesre kerul :D Mar csak azert is, mert a statiszikai uton zajlo korelacio a bejovo es kimeno mail-ek logjai kozott egyfajta "SAV statiszika" cimszo alatt csak ajanlasokat gyart, ami automatikusan nem kerul blokkolasra ettol meg, foleg mivel pontatlan is tud lenni annak jellege miatt. Ha valami eleg "feltuno" akkor kerul ellenorzesre, abban lehet mar "aktiv teszt is", de ez ugye nem minden mail fogadasnal tortenik tehat. Ez mar a statiszitkai "gyanus toplista" elemezesnel tortenik csak, es itt az elbiralas a tiltasra manualis megerositest kivan.
Lehet, ezt nevetsegesnek tartod, de ne feledjuk, hogy egy /15 tiltasa is vegulis hasonlo. Nezed a logokat (kvazi elemzed, statisztikat keszitesz), es az alapjan gyanus, hogy valahonnan tul sok szemet jon, eldontod, hogy tiltod-e stb, aztan tiltod. Szoval ha a fenti elmeletet viccesnek talalod, vagy akarmi, ne feledd, hogy minden ilyen kezi beavatkozas ugyanaz. Itt csak arrol van szo, hogy van ehhez tamogatas, hogy ne kelljen a logot turni allandoan, es legyenek kimutatasok, hasznalatra keszen. Persze ilyesmiket mas celra ia hasznalunk, de most ez kapcsolodott a temahoz eppen.
Veled ellentetben, nem allitom, hogy en tokeletes lennek, vagy a munkam az. En evek ota csiszolgatom ezeket allandoan. Nyilvan a szebb megoldas a content filter hasznalata (minnel tobb dolog a konkret level alpajan doljon el!), ahol nem az SMTP tranzkacio bizonyos parameterei (tudomisen peer MTA IP, annak reverze, HELO check, sender MX, stb stb stb) alapjan tortenk a donteshozatal, mert ugye a mail legitim voltat alapvetoen nem ez dontene el, hanem a mail tartalma ... Csak ugye, tudjuk, hogy content filter-bol lenyomni mindent nem olyan trivialis, gmail egesz jo ebben amugy. Sajnos az altalunk hasznalt content filter megoldas viszont nem az en dontesem ...
Amugy az idezett informacio forrassal ABSZOLUTE nem ertek egyet egy ponton, amikor azt targyalja, hogy a SAV egyik hatranya, hogy pl tipikusan noreply@-os feladoknal elofordul, hogy ott nem is akarnak fogadni. Ez szerintem braindead by design koncepcio. Pont a hirleveleknel lenne fontos (ahol ezt peldakent hozza fel!), hogy azt jol csinaljak, mert ott szokott meggyulni a baja az embernek azzal, hogy spammernek belyegeznek egy esetleg legitim hirlevelkuldot is, aki tenyleg nem ilyen-olyan megkerdojelzheto eredetu cimlistat hasznal stb stb. Ezt normalisan ugye ugye szokas csinalni, hogy a feladonak fogadnia is kene, es jobb esetben egyedileg generalt sender-ek vannak, igy az esetleges NDR akarmi visszakovetheto hogy melyik mail tranzakciora adott valasz, amibol statiszitka kepezheto, ellenrizheto kesobb is, extrem esetben kiveheto a cimlistabol az adott cim, ha ez jelenik meg a kimutatasban stb. Szerintem a noreply@-os felado, ahol nem is fogadnak valaszt stb, de tomegevel kuldenek ki, az alapvetoen hibas koncepcio, ha mar itt tartunk ... De biztos vagyok benne, hogy majd kimutatod, hogy az a velemenyem is "balfasz" ... Ezert is nehez hirlevelet jol kuldeni, es nem trivialis, jonnek nalunk is ugyfelek, akik legalabbis allitasuk szerint legitim hirlevel kuldok lennenek (nem spammerek) es azt gondoljak, hogy feldobnak egy postfix/exim-et, irnak kis script-et, hasznalnak kesz megoldast mind1, es problem solved. Azert hirlevelet JOL kuldeni nehez am (es most nem a spammerekre celzok meg a "szukre hatarteruletekre", hanem aki tenyleg "legitim" hirleveleket akarnak kuldeni, es szeretnek jol csinalni, csak kisse naivak, hogy ezt 5 perc alatt osszeutik, aztan boldogsag, tobbe ra sem kell nezniuk stb stb, erted ...).
Ennek ellenere, mielott a fentibe is belekotsz, nalunk a levelezes alapvetoen harom iranyban megy ki. Az NDR-ek (bar ezek mennyisege idealis esetben nulla kene hogy legyen - ha mi vagyunk az eloallitok -, sajnos nem az, de minimalizalni mindig probalni kell), az empirikus tapasztali lista alapjan kepzodo "hirlevel" kategoria, ami altalaban a noreply es hasonlo local part-os dolgokat jelenti (ezek egy resze tapasztalati, mas resze adodhat pl a fenti jellegu automatizalt log analizis eredmenyekeppen), illetve a "maradek". Ezek maskepp vannak kezelve amugy mind. Ez nemikepp igaz a be es a kimeno iranyokra is a mail forgalmunk tekinteteben.
De azert csipem am, hogy barmit mondok az "balfasz" meg "pure BS", ugyanakkor az szerinted teljesen rendben van, hogy egy lathatoan magyar IP cim tartomanybol /15-ot tiltunk csak ugy? Elmondom, en ezt hogy szoktam, de biztos ez is "pure BS" szerinted ... IP szinen tiltast a legritkabb esetben eszkozolok, akkor, ha olyan merteku a forgalom, ami mar konkretan a rendszer mukodeset zavarja (=extrem nagy terheles). Ez azert eleg ritka. Mas esetben, SMTP szinten kerul elutasitasra a cucc. Ilyen esetben lehetoleg mindig normalis uzenettel utasitjuk el. Ha pl konkretan egy jol korvonalazhato spam tipusrol van szo, es mondjuk egy IP-rol toljak mint allat, es kb mind uaz, akkor az uzenetbe szoktam irni idopontot, sender-t, es message-id-et is, ezzel segitve a masik oldal munkajat, hogy ha belefut ebbe, azonnal keresgelhet magana, hogy mi volt ez. Persze, biztos ez is balfaszsag, es szerinted erdemes IP szinten blokkolni, foleg egy egesz /15-ot valoban. A fenti, es hasonlo policy-kkal mindig azt probalom elerni, hogy lehetoleg postmaster-barat legyen, es a masik oldal tudja, mi a gond, akar anelkul is, hogy felvenne velunk a kapcsolatot kulon. Azt nem allitom, hogy mindig sikerul ez :D de torekedek ra (tudom, tudom, a te allaspontod az, hogy mit erdekel engem, majd leboxoljak egymassal ...). Ha egy nagyobb tartomannyal van gond, arra nalunk log analizis van, nem tiltunk vakon. Pl peer MTA IP eloszolas vizsgalat a tartomanyon belul (valoban erdemes-e a teljes tartomanyt tiltani, vagy ezt fontolgatni). Aztan van olyasmi, hogy pl reverz check, hatha DNS reverz alapjan erdemesebb megfogni, itt meg pattern felismeres is van pl generalt reverzekre, meg ilyesmi. De ez is biztos pure BS, es a legjobb tiltani egy egesz /15-ot azonnal, nem gondolkodva, valoban, en kerek elnezest :-D
Oke, beismerem, en sem tartom mindig magam a sajat elveimhez. Pl nalunk tiltva van pl egy /8 is :-D Azonban az sem IP szinten, hanem ertelmes SMTP valasszal. De szerintem fontos merlegeleni a nagyobb tartomanyok tiltasat. A pelda /8 amugy valami kinai vacak. Ott is komoly log analizis zajlott (sot ott az atlagosanal nagyobb is), illetve minden hibajegy kapcsolatba hozhato tiltasi policy-kkal, merlegelve a tiltas hatekonysaga / reklamaciok aranyat. Erre a /8-ra talan masfel ev alatt egyetlen bejelentes jott. Persze, bevallom, ez igy is meredek lehet meg (megiscsak egy /8).
Erdekes meg hozzaszolasodban, hogy remekul tudsz kritizalni, de az onkritika keves: arra tovabbra sem kaptam valaszt, hogy szerintem elegge boritekolhato az eredmeny, ha tiltasz egy magyar ISP-bol egy /15-ot "csak ugy" ... Most tegyuk fel egy pillanatra (elozo hozzaszolasomban is emlitettem), hogy nalunk semmi "ellenrakcio" nincs. Ebbol akkor is velhetoen gond lesz, ez boritekolhato ... Opps, kozben latom a masodik hozzaszolasod, velemenyed szerint a SAV "eszetlen". Egy /15-os tiltasa ugy vakon bezzeg teljesen rendben van, ugye? :) Santit nekem ez a "en tokeltes vagyok, te meg pure BS-ekkel dobalozol, meg eszetlen dolgokat csinalsz" kioktatasod iranyomba .... Tovabba olyan bejelentes is eljutott hozzam, hogy valaki azert tiltotta a /15-ot mert "hup-on latta", ez volt az indoklas. Ez is erdekes :-D Foleg, hogy amugy a reklamacio arrol szolt, hogy o nem tud nekunk (=inviteles ugyfeleknek) kuldeni. Nalunk pl az o eseteben semmifele titlas nem volt eszkozolve, egyszeruen magat vagta el egy ip szintu blokkolassal a teljes /15-re. Ez azert szerintem kicsit vicces. Sajat maga policy-je miatt reklamalt nalunk, ahogy eltavolitotta, mukodott is.
Meg a masodik reakciodbol:
ez neked miert is faj? Ha xy ugy dont, hogy nem kellenek az inviteles halozatbol jovo levelek, akkor az az o balheja. Biztos egyeztette a fonokevel. Ha nem, majd lesz egy deathmatch-uk. De ennek semmi koze ahhoz, hogy te miert ilyen elbaszott modon akarod szurni a spam(mer)eket? Semmi.
Ez megint tereles. Nekem ne fajjon semmi, tok jo a policy a /15 tiltasa, de az en policy-aim mind szarok meg eszetlenek meg elbaszottak. Gratulalok, miszter tokeletes, jol megmondtad :) Azert faj, mert munkam soran hozzam jutnak el a bejelentesek, ha elso, masodik stb koros hibakezelesben nem tudjak lekezelni, es olyan szintuve no a problema. Az idom meg nem vegtelen (ez persze onzo szempont volt, korrektebb megfogalmazas: ugyfeleink nekunk adjak le hibara, ennek koltsege van nyilvan aztan, hogy ezeket a hibakat kezelni kell ...).. Amugy ja, biztos egyeztetett a fonokovel. Lasd pl a fenti eset, aki sajat magat tiltotta ki tolunk kvazi, es ra sem jott, csak az volt a reakcio, hogy "dehat a hup-on irtak!" ;-P Nem tudom, lehet kulonbozoek vagyunk, nekem amugy is "faj", en probalok masokra figyelni, es nem vakon tiltogatni. Ez nem azt jelenti, hogy mindig sikerul persze :( De ahogy fentebb is jeleztem, ennel a konkret esetnel legalabbis ahogy neztem legutobb is messze nem volt annyi tiltas belole, mint egy automatikus SAV cuccos eseten lenne, es valoszinuleg/remelehetoleg kevesebb kellemetlenseget is okozott (szembeallitva azzal, hogy egy jol iranyzott /15 kitiltasa bezzeg milyen baratsagos es okoz-e problemat ...). A kerdesedre valaszolva: nagyon is sok koze van, hiszen ez az egesz tema elo sem jott volna, ha nincs az elbaszott /15 tiltas otlete valami okostojasnak, ahelyett hogy elgondolkodik, milyen nagy tartomany ez, mi lehet ott, tenyleg az egeszet tiltani kell-e, tenyleg nem lenne-e jobb smtp szinten valaszt adva csinalni, stb ... Igen, es elnezest, hogy lelkiismeretesen vegzem a munkam es ERDEKELNEK a dolgok, szerinted ne fajjon nekem semmi, majd leboxoljak az emberek/fonokok/miegymas, es kesz, kalap kabat, szarjuk le.
De, hogy ne csak lebaszas legyen a valaszban, ime par link arrol, hogy miert nem jo a sender address verification, hatha elolvasod, megerted, cselekszel, es a vilag egy kicsit jobb hely lesz:
OMG. Te aztan bekepzelt es lekezelo vagy, GRTALULALOK. Szerintem ez a toplistas lenezesi kiserlet, ami balul sult el. Nagyon orulok, hogy erdemi kommunikacio helyett a masik lenezesenek kiserletben latod a megoldast, a konstruktiv beszelgetes helyett ... Megjegyzem, egy /15 tiltasi is eleg onkenyes, es jobb hely lenne a vilag, ha nem alkalmazna ilyet senki, foleg melyebb elemzes nelkul, hogy ez adott esetben biztos jo otlet-e! Raadasul abban sem ertek egyet, hogy a SAV alapvetoen rossz. latod a spam wikia oldal is emlit elonyoket is. De ha ez nem eleg, lasd a hosszu leirasom, mi nem is ezt implementaltuk, mi vegulis csak log analizalas alapjan vegzunk statisztikakat, amit idonent ellenorzunk aztan ...
Utolso kerdesem/keresem: en probaltam volna nem szemelyeskedni, de nem lehetne visszafogni magad es emberi, technikai ervekkel jonni a szokasos "pure BS", "elbaszott", "nem nezem ki beloled" stb remek kis "ervek" helyett, illetve ilyen bicskanyitogtato "hatha megerted, es akkor jobb hely lesz a vilag" nevetseges nincs mas erved helyett? Kisse nevetseges vagy, ne haragudj :( Jobb lett volna ha normalisan kezdesz ennek neki, mellozve a szemelyeskedest. En oszinten, azert reagaltam itt, hatha tudok segiteni, megvilagitani a dolgokat, vagy magyarazatot adni a miertekre, lehet nem kellett volna, ha csak a flame-re megy ki. Persze, ahogy latom, ebbol megint azt fogod kihozni, hogy en vagyok a balfasz es lam "megfutamodok". Felolem beszelhetunk tovabb a temarol, de kerlek emberibb keretek koze szoritkozz, cserebe en is megigerem, hogy visszafogom a hasonlo valaszkent hasznalt jelzok hasznalatat, mert teny, hogy ez sem szep dolog, es az is gyerekes, hogy "de o kezdte" ;-P Csak hogy ne mondd, hogy nincs onkritikam. Szoval legyszi ezeket mellozuk, cserebe en is megprobalom ezeket mellozni, oke? :) Ismet kiemelnem, SEMMI bajom veled emberileg semmi, csak technikai kerdesekrol beszelgetunk. Ezert sem ertem ezeket a lenezeseket, folenyeskedeseket stb ... Ez a gyenge ember mentsvara, amikor ezzel operal ...
Kisse hosszu bejegyzes lett, es van amit atirtam (igen, a fogalmazas nem mindig az erossegem ... ezert is mindjart megkapom a magamet), igy lehet nehol kisse kusza lett, amikor "osszeszerkeztettem".