spam + Mail Delivery Report

Írj privátot, segítek megoldani.

Keves gkita,

Nagyon úgy tűnik, hogy a DSN az még a filterezés előtti "rétegben" zajlik. Én a saját szerveremen inkább letiltottam. Mivel before-queue filtert használok, ezért a küldő így is értesülni fog (a megnyitott SMTP kapcsolaton keresztül permanens hibával visszadobja a szerver) arról, ha nincs sikeres kézbesítés.

Cégünk mindig az Ön rendelkezésére áll, Asszonyom! :)

az adatot el kene valasztani a kodtol: a my %IP_BLACKLIST = ()-et nem a kodban tarolnam, hanem vagy valami sql-ben, vagy dns-ben...

--
O1G = orbanegygeci

Ez teljes egeszeben konfiguralhato.
Nalam konkretan 1 ora.

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".

Azon meg nem kell csodalkozni, ha valaki banataban kib*asz egy /15-ot a halozatotokbol. En pl. riportoltam egy buzi spammert, de arra kellett rajonnom, hogy az invitel/tech egy spammerbarat szolgaltato. Vegul is en csak a pofam jartattam nekik, a spammer meg fizetett. Ertem en, hogy mennek a dolgok. Meg mielott kerdezned: es nem egy spammer van a halozatotokon.

Na igen, erre nehez mit mondani. Alapvetoen nem tudom ezt teljes mertekben cafolni. Sajnos tudok rola, hogy van 1-2 ilyen ugyfel en is, de szamomra "erinthetetlenek", mert hat .... na pont azert, amit mondtal (fizet), vagy tudomisen miert. Ha rajtam mulna, nyilvan mennenek a fenebe. Azonban akiket en ismerek ilyeneket (persze nevet nem fogok irni, azt legyszi ne vard ..) eleg jol korvonalazhatoan egy szuk tartomanyban vannak, szoval minimalis log analizissel es vizsgalattal kideritheto, es tilthato barkinek. Jo, nem egy ilyen van, en is tudok legalabb 2 bagazsrol. De akkor sem olyan nagy a szamuk, hogy nem lehetne behatarolni, es egy teljes /15-ot dobni kene a levesbe. Az a baj, hogy en is nagyreszt persze csak a "kozponti" mail infrastrukturankat nezem. Arra nincs rahatasom, hogy XYZ ugyfel dedikalt berelt virt./ gepein vagy hostolt szerverein mi van, stb. Illetve azokkal en nem is foglalkozok, nem hozzam tartozik. Mielott megszol valaki erte, en minden esetben, ha hozzam eljut ilyan panasz, akkor is tovabbitom a megfelelo embereknek, ha erdemben nekem ez nem is lenne feladatom. Azt, hogy utana mi tortenik vele ... Viszont, ha igazsagosak akarunk lenni, tapasztalataim alapjan sajnos az latszik, hogy minden trivialisnal nagyobb szolgaltatonal (nyilvan ezt erzesre mondom, nem feltetlen az igazsag 100%-osan!) vannak ilyenek sajnos :(

A masik gondom alapvetoen az, hogy a jelzett temaban tobb hibabejelentes eljutott hozzam is. Olyanok is, sot abbol volt a tobb joval, ahol nem a mi tiltasunkon/akarminken mult, hanem egyszeruen nem vette at a cel (nem a mi tiltasunk miatt ebben az esetben). Mint mar emlitettem olyan is volt hibajegyben am, hogy "azert tiltottuk mert a hup-on irtak, hogy tiltani erdemes". Te meg ugye arra celoztal, hogy "kit erdekel, tiltja az ember". Na erre mondom en, hogy hat nem tudom, nyilvan azert mert egy forumban olvasom, nem fogok senkit tiltani, ez azert veszelyes jatek. Szerintem egy privat, hobby, 1-2 fos kft, stb jellegu felhasznalasnal nagyobb mail infrastruktura adminjakent legyen mar az emberben annyi felelosegerzet, hogy nem ossze-vissza tilt minden alapjan, amit olvas a neten itt-ott, anelkul hogy barminek utana nezne, logot vizsgalna, analizalna stb. De biztos velem van a baj, hogy engem erdekel, es probalom lelkiismertesen csinalni ...

Az ebben a durva, hogy a hibabejelentesek elott egyetlen reklmacio sem jutott el hozzam legalabbis, hogy gond lenne, sok spam jon innen-onnan (most egy dolog, hogy tudom-e kezelni, mert pl nem egy fenti "fontos ugyfel" [...] de attol mindenkeppen vizsgaltam volna legalabb). Sot a kerdeses tiltasok beallasa utani hibajegyekben is elo kerult a "masik oldal" aki tiltotta a /15-ot, es egyetlen ertelmes valaszt nem kaptam, amikor kertem az ugyfelkapcsolatos munkatarsaktol peldakat stb, hogy vegre kideruljon mi miatt tiltottak ezt egyaltalan! Sot, ez mind a mai napig, amikor ezt a hozzaszolast most potyogom meg mindig nem derult ki, semmi konkretum ... pedig kozben volt itt mar szamtalan hibajegy, flame itt :) stb ... De a lenyeg meg mindig nem derult ki. Hibajegyekben is volt olyan hogy "mert omlik a spam a /15-bol". Erre visszakerdeztem, hogy peldak, stb? Erre a valasz a fenti: "jaaa hat a hup-on olvastam" :D hat remek :)

Felre ne ertsd, nem allitom, hogy feltetlen tudtam volna tenni valamit, de legalabb tudok rola, utana tudok nezni, es akkor eleve abban is korultekintobb vagyok, hogy a fenti log analizis alapu "javasolt tiltasok" kapcsan mire mondunk ament es mit nem, de ugye nem tudtam errol ... Sot meg most sem tudom, mi az alapja ennek az egesznek, csak irogatunk itt egymasnak szaporan :D Ez azert szerintem kicsit "vicces" :)

ezek a stupidabb spammerek. Ha ki akarnek baszni veled, keresnek egy csomo ilyen balfasz antispam vedelmet hasznalo mafla szervert, es olyan letezo domaint hasznalnek, aminek nincs spf/dkim beallitasa, mondjuk invitel.hu. Biztos lenne egy kis spike a grafikonokon :-)

Hiaba mondod, hogy stupid spammer, a szamok nem hazudnak. Rengeteg ilyen spam jon be, amit ilyesmi mechanizmusok megallitanak nalunk, es pl adott esetben mas nem, vagy joval kisebb aranyban. Mint mondtam, nem csak otletszeruen csinalom ezeket, hanem statisztika alapjan az is vizsgalva van, hogy van-e ertelme egy adott dolognak vagy nincs. Jelen esetben van, meg akkor is, ha szerinted ilyen spammer nincs, vagy csak a stupid. Ezek szerint sok stupid van, na :D A lenyegi mondanivalom: lehet szerinted (vagy mas szerint is) tok eszetlen/balfasz stb policy is, ha egyszer HATASOS, es olyan teren is hatasos marmint, hogy nem okoz tobb reklamaciot, mint amennyi elonyt viszont jelent ... Sok MTA admin elkoveti azt a hibat, hogy kesz tenykent kezeli, hogy XYZ1 megoldas szar, XYZ2 a tuti, stb. Ez nem ilyen fekete-feher, es nyilvan ossze lehet utni total "fura" egyeni policy-kat is stb. Igazabol azt kene latni, hogy kene egy kis onkontrol, "feedback loop", hogy mennyire hatekony, mennyire reklamalt, mennyire "utalt", mennyire eroforrasigenyes, mennyibe kerul, stb stb jellegu statisztika keszuljon, es az alapjan legyen mindig aktualizalva a kerdeses megoldas, mert ugye ez nem egy static allapot ...

invitel.hu -nak van SPF rekordja ... Az teny, hogy nem tul hatekony mivel ~all a vege. De ugye ez megint olyan dolog, hogy nem hasznalhatok -all -t, mert annak messzemeno kovetkezmenyei lennenek, igy is tapasztalataim szerint az ugyfelek eloszoretettel varialnak ossze-vissza, mi mail szerverunkon kuldenek ki de gmail.com-os feladoval, freemail.hu -ssal, stb stb, ezen nehez lenne szigoritani hatalmas felhaborodas nelkul ... Masreszt igen, eleg "sok mindent" megenged a softfail-on kivul is marmint sajnos, ez se igy volt eredetileg, empirikus tapasztalat volt (megint a feedback loop), hogy sajna van itt gond, ha nagyon szigoruan hagyjuk.

Abban viszont igazad van hogy DKIM nincs :-(

Csak hogy valaszoljak masra is:

UCEprotect level1. Feljebb en nem mennek, mert abban mar "artatlan" cimek is vannak (ahogy a /15-ben is ...)!!! Itt is, mint minden dontes, veled ellentetben nem az alapjan dol el, hogy szerinted vagy barki mas szerint mi a hulyeseg meg mi nem (na jo persze racionalis keretek kozott, a mail szerverek lekapcsolasa biztos segitene a kevesebb spam elereseben ...), hanem mi jon ki a tapasztalatok, gyakorlat alapjan, milyen a hatekonysag/reklamaciok szama, stb stb. Hadd aruljak el egy titkot: mi is voltunk *anno* UCEprotect BL-en, nem is egyszer. Sot mas nepszerubb RBL listan is. Nyilvan nem epp 1-2 db ugyfelunk van stb, ok meg kuldenek leveleket. neha ugy is, hogy nem is tudnak rola, ha erted mire gondolok stb :)

DE, es a fontos resze:

Biztos en csinalok valamit rosszul, de erdekes modon ha jol remlik az elmult 1-2 evben a kozponti 'naaaagy' kimeno mail szerverunk egy nepszerubb BL-en (nyilvan nem szamitva olyat ami abszulte "eszement" de tenyleg, pl az APEWS) sem volt rajta. Egy CBL volt par honapja (?), amire visszkaptuk a hozzajuk intezett kerdesemre, hogy teves listazas volt valami CBL-es atszervezes miatt (ami eleg sok mast is erintett), es leszedtek minket ASAP. Mielott megint szemelyeskedesbe csap at a dolog, es esetleg kitalalod, hogy hazudok, idezem a valaszukat:

"Due to a mistake in a new rule, a number of erroneous listings were published in the CBL/XBL (included in Spamhaus Zen). A few of these listings appeared 2017-07-06 which were removed within a few hours. A few more appeared today, and all were removed at approximately 5:45pm UTC and things have been corrected to not happen again. If you had done an earlier lookup and seen a "bot name" of "c_sludge", this applies to use. Our apologies for the inconvenience. "

Szoval, biztos en vagyok a buta, de hogy tudom megoldani azt, hogy ne keruljunk fel BL-ekre, a te ugyfeleid meg igen, akiknek aztan magyarazhatod, hogy jaaa az invitel a hulye mert uceprotect-et hasznal. Amugy - tudomasom szerint - az uceprotect level1 azokat listazza ahonnan mail-ek mentek spamtrap-ekre, tehat eleg egyertelmu, hogy tenyleg spam ment ki onnan. Tehat eleg egyertelmu, hogy ott gond van, amit tiltani kellene. Legalabbis elviekben, nem tudom mit vitatsz itt, hogy az UCEprotect hazudik, es olyat is felnyom level1-re, ahol nem is volt ilyen? Vagy csak az faj, hogy nehez lekerulni rola? Marmint, hogy 7 nap expire time, meg kernenek penzt is, ha nagyon kell a removal (ha jol emlekszem, hogy mux a dolog ...).

Ha pedig erdekel: az is a folyamat resze, hogy a kulonbozo policy-ainkat felulvizsgaljuk idoszakonket, hogy "megeri-e" alkalmazni, nyilvan ha tobbet art, mint hasznal, akkor nem feltetlen ... Jelen esetben is nyilvan az is beletartozik, hogy hany "nagyon valoszinuleg" (statisztika alapjan marmint) spammer forrastol szabaditott meg, ami mas BL-en pl nincs rajta feltetlen.

Pont te voltal az, aki fennhangon hirdetted, hogy a "kit erdekel" hozzaallas a megfelelo tiltasi policy-k hasznalatanal. Most viszont ez faj, ha en is ezt mondanam, ha zavar az uceprotect? :) Kicsit fura ez nekem, es tenyleg nem flame miatt irom, csak elegge szelektalsz. Megjegyzem, ez is csak elvi kerdes, en veled ellentetben NEM mondom hogy kit erdekel, mint emlitettem, rendszeresen ellenorizve vagyon statisztikak alapjan hogy mennyire hatekony, mennyire problemas stb stb egy eszkozolt policy nalunk. Ennek egy resze nyilvan a mail logokbol fakad, de olyan faktorok is vannak benne, mint hibabejelentesek szama, azok ertekelese, stb stb stb. Pl konkretan volt olyan megkeresesunk, ami mint kiderult, sajat magunk altal is tiltasra kerult volna, tehat ez megerositi, hogy velhetoen nem kamu dolgokat vesznek fel UCEprotect-re.

De amugy igazat adok neked abban a kerdesben, hogy az is lenyeges, mennyire faj egy-egy dolog az ugyfeleknek/felhasznaloknak stb. Nyilvan egy rendszer biztonsagat,szureseit,akarmit egeszen a hasznalhatatlansagig lehet novelni ;-P Az viszont mar a lo tulso oldala. Ezert hasznaljuk azt a feedback mechanizmust, hogy mindig ki is ertekeljuk milyen hatasai vannak a levelezesre ugy altalaban az altalunk eszkozolt policy-knak. Abban is igazad van, hogy barmikor elerheti azt a szintet, hogy tobb problemat okoz, mint amennyire megold, akkor nyilvan ki kell vezetni, mert tobbe mar nem a "hasznos" mezo iranyaba fordul a mutato, hanem atmegy a semlegesen at a "karos" mezobe ... Csak ugye ezt nem levetitve X ugyfelre kell nezni (akivel pl te talalkoztal ezek szerint, amit fentebb leirtal?) hanem globalisan, hogy a teljes mail forgalmunkra, a teljes ugyfelbazisunkra, es ugy altalaban a veluk kommunikalo osszes mail partnerre nezve ez mit jelent. Es tudom mar unsz, ennek helyes kimutatasara statiszika kell, kulonben jonne az, hogy "szerintem" hulyeseg, "szerintem" nem hulyeseg stb stb, konkretumok nelkul nehez megmondani ... Nem szeretek a levegobe beszelni, ezert ellenrozom mindig pl ilyesmiket is, hogy ne azon muljon, hogy az en lazalmomat kell megvalositani, es kozben mindenki mas szerint hulyeseg. Majd a szamok megmutatjak, en ezen az elven vagyok. Persze, johet a vicces resz, hogy mint tudjuk "nem hiszek az olyen statisztikaban amit nem en hamisitottam szemelyesen" es hasonlok, de ezt csak a hangulat oldasa vegett csempesztem ide, remelem ezt legalabb ertekeled, ha mast nem is ;-P

Probaltam ismet kifejtos lenni, hatha esetleg legalabb elgondolkozol azon, hogy ne nezz tovabb teljesen hulyenek mint eddig tetted itt a beszelgetesink soran.

Jah es bocs, tenyleg szerkesztettem a valaszom kozben, igy nehez ha erdemben valaszolni, ez igaz. Remelem a barati hang megtalalasara tett kiserleteim elobb-utobb eredmenyre vezet, es ha van is megbeszelni valo, azt mar "nemikeppen kedvesebben" (ergo nem ... ize, bocs : ... bunkon, lenezoen) is meg tudod fogalmazni. Hidd el, pont nincs erdekemben senkit sem direkt szivatni, probaltam a valaszaimban is talan tulzott meretekben is vazolni, hogy mennyire fontosnak tartom azt, hogy lehetoleg ne szivassak masokat, es ugy legyen hatekony. Ez persze sajna nem azt jelenti, hogy nem szivatok meg neha valakit, mert tokeletes megoldas nincs, max csak kevesbe tokeletes, es tokeletesebb ... es ennek skalaja. Erted.

Valoban. De akkor tovabb megyek: utolagos bejelentes sem volt, ha mondhatom igy. Azaz, az osszes bejelentett problemanal ami hozzam eljutott, visszakerdeztem, hogy konkret pelda/peldak? Valaszok? Ilyenek: "hat mert omlik a spam, nem tudok konkret peldakat adni", meg "a hup-on olvastam", stb (pedig egyes peldak eseten a mi ugyfeleink jelentettek be, akik idezgettek a "masik oldal" valaszait, hogy ok miert tiltottak - bar ellenkezore is volt pelda, amikor tolunk fuggetlen fel vegulis sajat magat tiltotta ki tolunk, vagy hat mindket iranyban vegulis, aztan a sajat hulyesege miatt sirt nalunk ...). Most ott tartunk, hogy meg _mindig_ nem tudom, hogy konkretan mirol van/volt szo :-O Mert egyetlen konkretum se volt azota se ... Az egy dolog, hogy sokan elvesztik (meg tudom erteni!) a bizadalmukat abban, hogy riportoljak a gondot (pont azert, amit te is leirtal ... nem tudlak megcafolni, hogy nekem nincs ilyen tapasztalatom szinten ...), mielott tiltanak. Itt az a plusz fura, hogy utolag sem derult ki szamomra semmi ...

Az masik erdekes dolog ebben a szituban viszont az, hogy igy nekem "erzesre" is sokkal komolyabb gondnak tunik, mint egy "atlagos" spam bejelentes, ami szokott lenni, meg tenyleg, /15-rol beszelnek, miegymas. Azert ez a /15 a vesszoparipam tobbek kozott (nem csak ezert, de ...), mert arra utal, hogy nem elszigetelt eset volt, es ha nem is az egesz /15 (nyilvan ...), valoszinu csak van alapja, hogy azon belul is tobb "gocpont" volt. Ha csak egy lett volna, csak valoszinubb, hogy azt az egyet talaltak + tiltottak volna. A sajat erdekem is, hogy tudjak ezekrol, meg elvileg nyilvan a cegem erdeke is ... Ezert nyilvan erdekel is :)

És elgondolkodtam egy olyanon is, hogy ideiglenes hibakóddal kellene visszadobni a szemetet, álljon a queue-ban a spammer-nél...

:) Hat ez tolem sem all tavol idonkent, hogy oszinten bevaljam :)

Igazság szerint az info@ cegnev@ és társaira itthon valóban lehet jogilag mindenfélét küldözgetni, mert nem személyhez kötött. Technikailag persze spamek, de ezzel nem lehet mit kezdeni sajnos. A tűzfalas tiltással nagyon nem értek egyet én sem, bár pár hete erősen megtelt a zoknim a sok fosgenerátorral és ipset-tel kombinált egyfajta smtp only fail2ban merült fel bennem. Aztán volt aki továbbment és a mindenféle "rosszaságok" (hibás smtp auth, nincs reverz, protokol hibák stbstb) alapján pontozta a hosztokat és egyelőre smtp szinten azokat kivágja. A tűzfalas vagy egyéb semmitmondó tiltással az a problémám, hogy néha mi is belefutunk, hogy valaki/valahol kivág vagy ilyen "you're not allowed" -osan "sokatmondó" hibát kapunk. Ezzel az a problémám, hogy ha a szokásos problémaforrásokat átnézve se találjuk meg a bűnöst, akkor pingvinezés jön. A bármilyen okból problémás küldőt én szeretném nyakon csípni és kezelni az issue-t, illetve az sem oldódik meg, hogy rendesen küldjünk emailt oda, ahol bannoltak emiatt.

Ideiglenes hibakóddal simán dobálunk vissza sokmindent, bár abból a megfontolásból, hogy valódi tech issueval kűzdőt vagy vétlent kevésbé szivassunk. (Egy épp kihagyó névszerver miatt kár teljesen visszavágni egy emailt MX, A rekord vagy reverz hibával.)

A konkrét hibabejelentés, azaz annak hiánya egy általános probléma. Rendszerint az "ömlik be a spam" jellegűek azt jelentik, hogy kettő nap alatt 1 darab valami spamjellegű eljutott az inboxába, mikor kiderül, hogy 10db mail van a spamfolderben és további N darabot ab ovo visszacsaptunk akkor körötte csend és néma tartomány. Talán a legaranyosabb volt, mikor megszakértették, hogy biztosan (101%!!!negy!) rossz a levelező szerver, hiszen 2-3 napja spamet sem kapott. A szörnyű valóság az volt, hogy néhány visszacsapott spamen kívül valóban nem kapott mailt.

mar leirtam, mit kell csinalni. Mi lenne, ha esetleg kiprobalnad?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...