mar elnezest, de nem te kerted az ekezest ("en vagyok a szerzoje szoval lehet szidni :D")? Aztan ha megkapod, akkor meg jol besertodsz? Ejnye mar. Azt meg kulon lajkolom, hogy milyen jol elbeszelgettel magaddal az en nevemben is. Kar, hogy zomeben a csak a sajat fejedben levo boszmesegeket adtad a szamba.
Veled ellentetben, nem allitom, hogy en tokeletes lennek,
a francba, irasba is adtam volna? Ja, nem (csak akartam :-)))
felve megjegyzem, hogy en fejlesztettem, tudom, mindjart jon az intelmed, hogy lam programozni sem tudok
mindig ennyire sundisznoba mesz, ha valaki egy kicsit megizzaszt? De most hogy leirtad, hogyan csinalod, azt kell mondjam, nem is annyira elbaszott (mondjuk mar nem is hasonlit a sender address verification-re). Legalabbis annak merteket csokkenti a log elemzese es a human faktor.
Nezed a logokat (kvazi elemzed, statisztikat keszitesz), es az alapjan gyanus, hogy valahonnan tul sok szemet jon, eldontod, hogy tiltod-e stb, aztan tiltod.
ez teljesen jo, en is igy csinalom. Meg meg sokan masok is. Talan meg ozs is par kommenttel fentebb.
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
igen, en is masszivan content filter parti vagyok (ha jo cuccot valasztott az ember). De legyunk realisak, sok szemetet mar az smtp fazisban el lehet szorni, csak aztan jok legyenek az ezen a szinten alkalmazott tesztek, nehogy tobb hatranya legyen, mint haszna.
noreply@-os feladoknal elofordul, hogy ott nem is akarnak fogadni. Ez szerintem braindead by design koncepcio.
ellenkezoleg. A level fejleceben a reply-to megfelelo beallitasaval mar olyan cimre mehet a valasz, ami mogott mailbox is van. De ezt fentebb irtam is.
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?
attol fugg, de ezt vilagosan le is irtam. Te is tiltasz egy /8-at, ami egy picit azert sulyosabb eset, mint egy /15. Nyilvan te is merlegelted, aztan dontottel. Mibol gondolod, hogy ozs, aki szinten igy tett, nem merlegelt? Nem tudhatod. Azt sem tudhatod, hogy jogos volt-e a felhaborodasa? Irtam peldakat (amiket nagyvonaluan elengedtel a fuled mellett), amelyek alapjan siman lehet, hogy igen. Jahogy ez a /15 magyar halozat. Ki nem szarja le?
Ha valaki ugy dont, hogy blokkolja (tok mindegy milyen szinten) az invitel colocation/dsl/cable/... halozatat, az az o szuveren dontese. Ha rosszul dontott, akkor viseli erte a felelosseget. Esetleg majd elmagyarazod neki, hogy elbasztad, ocsem. Nekem pl. van egy lebaszo sablonom, hamar megvan a level.
Most tegyuk fel egy pillanatra (elozo hozzaszolasomban is emlitettem), hogy nalunk semmi "ellenrakcio" nincs. Ebbol akkor is velhetoen gond lesz, ez boritekolhato
valahol a vilagban mindig van gond. De ne fajjon a te fejed az egesz vilag problemaja miatt. Neked eleg az, hogy te ne legy a problema forrasa. Ha feletek tiltjak a levelezest, akkor az a tuloldali smtp szerveren akad fenn, hozzad el se jut a problema (ha ok kepesek ertelmezni a logokat ill. tudja az ottani jobb kez, hogy mit csinalt a bal)
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 :)
igen! Ertem en, neked nem a /15-ben levo ugyfel gepek blokkolasa faj, hanem hogy beleesik a kb. 91.82.116.0/28 is, ahol a mail szervereitek vannak. De mennyivel jobban hangzik, jobban lehet sirni miatta, hogy xy /15-ot blokkolt, mig egy ~/28 blokkolasa kb. mindennapos eset.
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.
hat, ilyen ez a pop szakma. De a te korlatos idod sem menti azt, ha helytelenul blokkolsz egy masik gepet. De aterzem a fajdalmad: igen ritka az olyan supportos, akire 2-3 eset utan ra lehetne bizni egy ilyen ugy letisztazasat.
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,
na meselj mar, mi van ott (az emlitett /28-nyi inviteles smtp szervereken kivul)? DSL halozat? Colocation halozat? Cable? Mi van, ha elgondolkodott? Mi van, ha ozs is nezett logokat? Nem akarlak nagyon megingatni a vilagkepedben, de mas is szokott ilyet tenni.
Raadasul abban sem ertek egyet, hogy a SAV alapvetoen rossz. [...] lasd a hosszu leirasom, mi nem is ezt implementaltuk,
tehat nem annyira gaz a sender address verification, de azert mi a biztonsag kedveert nem is ezt implementaltuk. Ertem.
Na, de akkor beszelgessunk real business-rol. Mi van az uceprotect-tel? Mi van azzal, hogy az invitel / invitech le se szarja a spam bejelenteseket, mert csak az a zse erdekli, amit a spammer csenget? Csak hogy egy kicsit taguljon a vilagkeped, hogy vajon mi vezethet oda barkit is, hogy - o mily szornyuseg! - kibassza az invitel emlitett /15-et?
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...