Védekezés a SPAM-ak ellen. ( A tökéletes megoldás a problémára:)

Security-all

Hali!

Na jó legalábbis egy újabb ötlet a spamek elleni harcban.A gondolat a következőkből indul:
Nem olyan rég nézegetem az exim reject logomat. A legtöbb bejegyzés valamilyen botnet-ből jött.
Jelenlegi védekezési módszerek a spam-ek ellen (nagy vonalakban)
1. Felhasználói oldalon: friss vírusirtó szoftver használata.

2. ISP oldalon: az stmp portot csak a saját smtp szerverükre engedje ki. És ha egy elvetemült user az útlok-ot akarja használni. Azt csak ezen keresztül tehesse meg. Pont.

3.Smtp szerver oldalon:
3.a amavis, spamassassin és egyéb progik.
3.b A legfontosabb pedig mostanában pár rbl használata.

Eddig az alapfeltevés. A gondolatom pedig a következő:
Itt vannak az rbl-ek. Amik egy nagy adatbázisok a legtöbb spammer gép/isp-ről. (Igen az szolgáltató is hibás a dologban, sőt szerintem az smtp port tiltása egy nagyon fontos lépés lenne. ) Tehát ezt az adatbázist csak az smtp szerverek használják fel. De mi lenne akkor ha egy másik felhasználási módot is adnánk ennek az adatbázisnak. Nevezetesen a figyelem felhívást. Elődlegesen az isp figyelmeztetése az smtp port letiltására. Másodlagosan a vírusirtó használatára.

A megvalósítás nem is olyan bonyolult.
Pl: Egy apacs modul írása ami az rbl-ben szereplő ip címeket egy hiba oldara küldni. Vagy egy jomoola, drupal modul készítése ugyanilyen céllal.

Persze ennek az egésznek csak akkor lehetne valami értelme ha több nagyobb weboldal is csatlakozna az elképzeléshez.

Érdekelne, hogy kinek mi a véleménye a dologról.

  • 3869 megtekintés

( gthomas | 2008. 07. 12., szo – 10:32 )

Mi lenne ezen a hibaoldalon?

Az itthoni gépem pl. smtp szerver (fogad a 25-ös porton, küldeni az ISP-n keresztül küld), ezt most akkor megtehetném vagy sem?
Vagy csak a küldést tiltanád?

Valamilyen figyelmeztetés. Hogy hívja fel az isp-t mondja meg, hogy nem tud normálisan netezni, mert folyton ezt az üzit látja.

Persze így semmi gond nincs a dologgal. A küldés a gond.
Egyébként magyarországon ezek jól be vannak állítva. Fogadni miért ne lehessen. Az ötletnek ezt a részét már régóta kitalálták. Semmi új nincs benne. Csak nem nagyon jutott el nagyon sok isp-s "rendszergazdához"

Az iptables szabály egy natolt hálonál kb
iptables -a POSTROUTING -s belső_háló -d smtp_server --dport 25

vagy egy routoltnál:
iptables -a FORWARD -s belső_háló -d smtp_szerver --dport 25

es szerinted mibetelne beleirni a "klienseken futo spamelo xarba", hogy keresse meg az isp smtpjet? vagy netan szedje ki a surun hasznalt emailprogramok beallitasabol? es akkor meg smtp authhoz a jelszot is kiszedi... Utana isp lelohetne a szegeny juzer emailjet, aki ezert szejjelkurtolne neten miert xar xyz szolgaltato, mert nemtud levelet kuldeni...

---
Apple iMac 20"
áéíóöőúüű

1. A legtöbb hivatalos smtp szerveren fut egy legalább egy spamassassin. Különben egy hét és benne van egy rbl-ben. Ami viszont nem igaz "klienseken futo spamelo xarba"-okra.
2. Az smtp-t az otthoni felhasználók kb 3%-a használja. (Saját felmérés. Ugyanis én is egy isp-nek dolgozok).

ja vagy a spambot kiszedi mozillabul, a jelszot, esetleg winapi -n keresztul, elkuldeti outlook expressel, vagy egyszeruen csak pusztan mind a 2 levelezo, apijanak segitsegevel, pl outloknal tudom hogy siman, berakja, magaat a postazando uzenetek koze, mar olvasott flaggal, es ahogy juzer outlookot indit, rogton indulnak a levelek is. es siman eszre se veszi.

---
Apple iMac 20"
áéíóöőúüű

Szerintem meg lehetne oldani a problémát egyszerűen oly módon, hogy minden egyes levélküldéskor lenne azonosítás (pl. egy turing teszt). Személy szerint én nem fognám fel fárasztónak, ha ezzel kiküszöbölhetném a napi 40-50 e-mail szemetet amit kapok.

Ha sok levelet kell írni, akkor is elég lenne egy azonosítás, aztán csoportosan elmenne.

Az outlook és egyéb "szoftver" ill. user hülyesége ellen sajna nem lehet mit tenni. Hála még sose használtam. Igazán megmutathatná a user-nek a küldés előtt, hogy mik is lesznek kézbesítve. De legalább az automatizált küldések ki lennének ezzel küszöbölve.

Ezzel csak az a baj, hogy amikor küldöd a levelet. Akkor felveszed a kapcsolatot a saját smtp szervereddel. Aki tovább küldi a levelet a címzett smtp szervernek.
Viszont a spambot. Alapesetben nem a te smtp szerveredet használja hanem rögtön a küldő smtp szervernek küldi az anyagot. Mivel joga van. Ezt a jogot kéne megszüntetni.
De még egyszer ez nem az én öltletem, hanem egy régi trükk.Pl. ha az AH-tól veszed a netet. (amit egy földi halandó otthonra nem nagyon tehet meg). Akkor az ip csoport folyatatosan zaklat, hogy felkeröltél egy tiltólistára. Legyél szíves tegyél ellene.

( janoszen v | 2008. 07. 12., szo – 16:22 )

A következő tapasztalataim vannak:

  • Greylisting: eddig nem volt vele bajom, mindazonáltal lehet, hogy szívsz vele, ha valakinek CsótánySzoft SMTPje van.
  • RBL: ezzel több szívás volt, ismerős szolgáltatója automatikus spamtrapek révén bekerült és ezért nem tudott levelezni.
  • Earlytalker: Amikor megnyitja valaki az SMTP kapcsolatot, várunk egy kicsit. Ha a mi köszönésünk előtt belepofázok, akkor annak rendje és módja szerint elhajtjuk a retekbe. Mivel a spamelő SMTPk vírus payloadként érkeznek, szeretnek kicsik lenni és ilyesmire nincsenek fölkészítve. Probléma megint a CsótánySzoft SMTPkkel van, bár ezt talán már mindenki tudja.
  • Blacklist: Ha nem kell autentikált SMTPket fogadnod azon az IP címen, akkor gyönyörű szépen ki lehet szűrni a reverse DNS alapján azokat a tartományokat, akiktől nem óhajtunk levelet kapni.
  • HELO / Reverse DNS: Ha valaki nem tud normális helóval köszönni vagy a reverse DNSe nem stimmel, akkor ne akarjon levelezni. Kirívó példája ennek az a magyar nyelvű spammer, aki valami apache-php scripttel akart levelezni és csak annyit láttam a logban, hogy localhost.localdomain. Na ezen azóta is röhögök.
  • Fail2ban: Ha valaki spamet próbál küldeni és fennakad a fenti szűréseken, akkor a nevezett szoftverrel nyugodt szívvel lehet egy kicsit pihentetni a szerver tehermentesítése céljából.
  • Amavis: Korlátozottan van haszna egyedül, mivel post processingről van szó, nem hajtjuk el a spammert a vérbe.

Config opciók (DUH)

  • Nem küldünk bounceot.
  • VRFY parancs nincs.
  • Csak annak fogadunk el levelet, aki létezik is.
  • Nem csinálunk open relayt.
  • Spammernek lassan válaszolunk. (LAAASSSSAAAN MOOOONDOOOM HOOOGY MEEEGÉÉÉÉRTTTSD: NEEEEM NNNNYEEEERT)

Ami az SMTP protokollt illeti, szerintem értelmetlen róla vitázni, mert bármiféle fícsör azt követelné meg, hogy a világon mindenki upgradeljen. Arról nem is beszélve, hogy mindig lesznek gyűjtő SMTP-k a szolgáltatók részéről, amit nem lehet értelmesen megszűrni. Ergó le kéne cserélni az egész SMTP protokollt de erre kevés esélyt látok.

"Ha valaki nem tud normális helóval köszönni"

Otthonra ez lehet, hogy elmegy, de ahol nagyobb mennyiségben leveleznek emberek, és a leveleiket is meg szeretnék kapni, ez nem működik. (már persze kérdés, hogy mit értesz "normális helo" alatt, ha a gép IP-jére regisztrált PTR-t, akkor áll, amit mondtam, ha csak szintaktikai megfelelőséget, akkor kevésbé)

Hát ez otthonnál kicsit komolyabb, nagyjából napi 30.000 spamet szűrök a fenti módszerekkel (az earlytalkertől eltekintve, az még nincs implementálva). A normális helo-t arra értem, hogy a gépnek legyen reverse DNS-e és mutasson arra az IP címre, amiről beköszön.

Egyébként miért ne működne? Ezt kifejthetnéd, mert ezek csak a saját tapasztalataim, mondhatnám, nem értek hozzá csak kényszerűségből.

Itt arrol van szo, hogy te latatlanban spamnek minosited a bena mta-krol jovo levelet. Ebben csak annyi a problema, hogy nem is tudod, hogy hany (valojaban jo) levelet dobtal el.

Ezt csak azert latod "mukodonek", mert meg egy ugyfeled sem verte az ajtot, hogy miert nem jutott el hozza nagy megendelese...

ASK Me No Questions, I'll Tell You No Lies

RFC-2821
"4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)

These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.

Tehát a küldő betolhat A.B.C.D -t is a helo/ehlo mögé, akkor, ha nincs revese... Ha ezt megtekernék úgy valahogy, hogy "argument field MUST contains the fully-qualified domain name of the SMTP client.", illetve hozzátennék a revese map kötelező meglétét, akkor lenne korrekt a HELO/EHLO ellenőrzés. Szerintem...

Mi olyan megoldast fejlesztettunk ki, ami a fentieket kombinalja, pontszamokat ad minden hibara (helo, revdns, dnsbl-ek, sajat local ip black/whitelistek, stb). Ha eleg alacsony ez a pontszam, akkor rogton fogadjuk a levelet ((utana persze meg at kell menjen a tartalomszuresen, virus ellenorzes 3 motorral, spamszures kulonozo modszerekkel stb), ha tul magas a pontszam, akkor reject-eljuk 550-el, egyebkent meg greylisting (450-el elutasitjuk, a pontszmatol fuggo idotartamra). Ja es kozben joooo lasssaaan valaszolunk neki, ha sok hibapontja van, akar 2 percig is elbeszelgetunk vele.

1 eve megy elesben, kb 2000 postafiokra, eddig 1 panasz se volt. a nemspam levelek tobbsege kesleltetes nelkul bejon, a kesleltetett levelek headerjeit megnezve mind "retekszoft" programmal, foleg web-es cuccokkal, vagy home-szerverekkel kuldott levelek, es kb a fele spam.

A'rpi

( sj | 2008. 07. 12., szo – 16:37 )

A t-online mar meglepte, hogy a dinamikus pool-jabol default csak az o smtp szerveren keresztul lehet levelet kuldeni. Idovel a tobbiek is meg fogjak lepni. Ez egeszen addig nagyon jo is lesz, amig a bot szoftverek nem keresik meg es olvassak ki az outlook beallitasait, jelszoval, mindenestul. Amelyik gepre fel tud maszni a bot, azon (99+%) van outlook es van ra egy masik 99+%-om, hogy meg is jegyeztetik az outlook-kal a jelszot. Ha ezt a pontot is elerjuk, akkor az smtp port tiltas aligha ad tovabbi vedelmet. Ezutan/ezzel egyutt lehet kvotazni a levelkuldest, es figyelni a gyanus jelensegeket, pl. 50k levelet kikuldott egy adsl-en logo gep. De ez sem lesz fajdalommentes.

Valaki irta a turing tesztet a level kuldesehez. Ezzel csak az a problema, hogy az smtp protokoll aligha tamogatja, ill. mi van az automatikus levelekkel (amelyeket nyilvan nem ember kuld el), es amelyek nem spamek?

akiktől nem óhajtunk levelet kapni.

Ezzel az szokott gond lenni, hogy (meg egy kisebb cegen belul is) a technikai szemelyzet velemenye nem feltetlen fedi a tobbi dolgozo elkepzeleset azokrol, "akiktol nem ohajtunk". ISP-nel ez meg nem johet szoba, mert honnan is tudhatnad te, hogy a te x ugyfeled kitol "nem ohajt"...

Ha valaki nem tud normális helóval köszönni vagy a reverse DNSe nem stimmel, akkor ne akarjon levelezni.

Szinten fals. Ez alapjan nem lehet eldonteni egy levelrol, hogy az spam vagy sem, es a fonokod, a megrendelotok aligha fogja ezt a hozzaallast elfogadni. Btw. ez nem is az apache+php nyugje, hanem a hasznalt mta bena konfigja. Arrol meg mit tehet xy, hogy a dns szolgaltatoja keptelen korrekt A+PTR rekordot bejegyezni neki? De ettol a level meg boven legitim lehet, amit ha izombol eldobsz, akkor fals pozitiv hibat vetsz, raadasul ugy, hogy nem is tudsz rola.

Nem küldünk bounceot.

Csak erdeklodom, hogy honnan tudja a felado, hogy elgepelte a cimzett nevet/cimet?

A spamassassin meg jo lehet egy hobbi gepen (napi 10k level alatt), de isp kornyezetben aligha kepes a terhelest kiszolgalni.

ASK Me No Questions, I'll Tell You No Lies

Ez alapjan nem lehet eldonteni egy levelrol, hogy az spam vagy sem, es a fonokod, a megrendelotok aligha fogja ezt a hozzaallast elfogadni Btw. ez nem is az apache+php nyugje, hanem a hasznalt mta bena konfigja.

Lehet csak én voltam a szerencsés, de eddig nekem ezzel nem volt problémám. Nyilván, vannak mindenféle csótány MTA-k, de sztem az lesz a legkissebb baja, hogy nekem nem tud levelet küldeni, sokkal inkább nálam nagyobb helyekre sem fog tudni küldeni és az ügyfele 5 perc múlva a szolgáltatónál van, hogy állítsa be normálisan az MTA-ját (már volt ilyenre példa).

Csak erdeklodom, hogy honnan tudja a felado, hogy elgepelte a cimzett nevet/cimet?

Onnan, hogy amikor egy nem létező mail címre akar levelet küldeni valaki ezen a hoston, azonnal visszaválaszolom neki, hogy kösz de ilyen nincs itt, és majd a másik MTA megküldi az elgépelő júzerének a bounceot.

Összegezve: Nyilván, lehet a lehető legnagyobb interoperabilitásra apellálni, de (szerintem) meg kell húzni valahol a határt (akár esetenként változóan). Szerencsére ma már a stock MTA-k normális configgal jönnek, kicsit azok száma (és ezt a lognézegetésem is igazolja) akik nem tudnak normális SMTP-t beszélni.

A helo/ehlo-t en is elvarnam mindenkitol, mivel mindenki jol felfogott erdeke, hogy egy mta igenis mta legyen (reverse dns, mx rekord, normalis beallitasok).. Aki nem veszi a faradtsagot, az ne szolgaltasson levelezest. A kliens ezesetben ugymond megszivta, de nem tehetetlen. Jelzi a problemat, avagy koltozik mashova. Ez is szolgaltatas - ha valaki szarul nyomja, akkor nem lesznek kliensei.

Bounceot mi sem kuldunk, legalabbis arrol semmikepp, hogy "viszlat es kosz a spameket!", ugyanis az ilyesmi csak backscatter, es nyeli a branert aki kapja - nekem is szolnak rendszeresen, hogy "sok volt ma a spam". Nem, sok volt a backscatter.. Az ellen sem egyszeru vedekezni, olyan megoldast meg nem lattam, amivel mindenki elegedett lett volna.

Spamassassinnal alig 50-60k levelet szurunk nap mint nap, es nem izzad az mta.

A spamassassin meg jo lehet egy hobbi gepen (napi 10k level alatt), de isp kornyezetben aligha kepes a terhelest kiszolgalni.

Nem osztom ezt a véleményt.

A keddi levelezésről készült összegzés... (2G-DDR2, 2.66GHz-P4) 

    2.781G  Bytes accepted                     2,985,579,491
    3.299G  Bytes delivered                    3,542,679,477
 ========   ================================================
 
    22708   Accepted                                  24.32%
    70673   Rejected                                  75.68%
 --------   ------------------------------------------------
    93381   Total                                    100.00%
 ========   ================================================
 
      911   Reject relay denied                        1.29%
     1251   Reject HELO/EHLO                           1.77%
     1579   Reject unknown user                        2.23%
       55   Reject sender address                      0.08%
       17   Reject client host                         0.02%
    39824   Reject unknown client host                56.35%
    27036   Reject RBL                                38.26%
 --------   ------------------------------------------------
    70673   Total Rejects                            100.00%
 ========   ================================================

Tehát a megmaradt 22708 levelet átnézte a spamassassin és nem szakadt bele a gép a munkába.

--
maszili

10 percenként ennyi levél az kb. 144 -szer annyi, mint a te gépeden. Ha 1 percenként ennyi, az 1440-szer. Természetesen csúcsterhelésre méretezünk, mert olyan nincs, hogy reggel meg délben nincs szolgáltatás, hajnal kettőkor meg egész gyors. De tegyük fel, hogy elég lesz 500 gép, mert a tied sincs teljesen kihasználva.

A mai kérdés, kellemesebb-e 20 gépen terhelés-elosztani, mint 500-on?

Tfh, hogy most indul a dolog és még hw vásárlás előtt áll a projekt, tehát a feladat megoldása harározza meg a gépek számát. A szélsőséges forgalom legyen a korábban említett ~2GByte,100k/perc.

Kíváncsi vagyok, hogy milyen megoldással lehet ekkora mennyiségű levelet átvizsgálni.

--
maszili

Noha ez nem az en felvetesem, de legyen, pelda egy lehetseges megoldasra (gepszamot nem irok):

1. Egy jominosegu feketelistat tukroznek a helyi halon 2 gepen, mondjuk rbldnsd futtatna.
2. Az mx-ek emellett eldobnak a nem letezo usernek szant leveleket, es a PTR nelkuli hosztoknak en is "unknown client host" hibat adnek vissza.
3. Emellett szurkelistat is hasznalnek a kulfoldi halozatok felol erkezo levelekre, a nagyobb free-mail szolgaltatok leveleit azonban atengednem ezen.
4a. Egy olyan (kereskedelmi?) statisztikai szurot hasznalnek, amelyik egy kozos (es memoriaba toltott) token adatbazist hasznal (es ezert villamgyors, ill. nem ellenoriznem a 128k-nal nagyobb leveleket, ezeknek csak egy elhanyagolhato resze spam)
4b. (esetleg statisztikai szuro helyett a cloudmark CMAE-t hasznalhatnam, ami minden gepen a localhost-on futna)

Vagy egy masik felallasban (B verzio):

Most is veszek annyi gepet (redundanciat is beleertve minden ertelemben), hogy elvigye ezt a levelszamot + eleteszek 2-3 db cloudmark gateway-t. (Ne kerdezd a gw-k arat).

ASK Me No Questions, I'll Tell You No Lies

( xclusiv v | 2008. 07. 12., szo – 17:20 )

Szerintem az egész koncepciónk rossz: tünetet (spam) kezelünk több/kevesebb (de nem tökéletes) hatékonysággal, nem pedig a tünet okát szüntetjük meg.

A spamszűrés, rbl, greylist, stb. pótcselekvés.
A spammer perelése is pótcselekvés.

Azt kellene megfogni, aki a spammer-nek fizet a szolgáltatásért. Minden spam-ben (vírus és phishing más téma) ott van egy webshop címe, ahonnan rendelhetsz viagra-t, replika órát, stb. Erre kellene rágyúrni: adott oldalt blokkolni/DOS-olni, tulajt megkeresni és karóba húzni, kamu rendelésekkel tönkretenni.

Ha jól emlékszem volt valami cég (talán izraeliek), akik ilyen spamvédelmet csináltak, de őket (még a szolgáltatójukat is) leDOS-olták elég gyorsan. Viszont egy kritikus tömeg fölött nem tudnának mit csinálni.
Erre kellene egy pippantó a gmail-ben, freemail-ben, minden komolyabb webmail rendszerben, hogy igen, akarom, hogy a címemre kapott spamben levő webshop-okban automatikusan generáljon kamu rendelést. Vagy ilyesmi. Ezzel ki lehetne szűrni a spam-eket, már csak a vírus/phishing dolgokkal kellene valamit kezdeni.

x

A Yahoonak volt ilyen letölthető képernyővédője, hogy a bizonyítottan spamelő szájtokat másodpercenként egyszer "meglátogatta". Ettől aztán szomorúak lettek a tulajdonosok és nagyon gyorsan jogi útra terelték az ügyet (éljen a liberalizmus) és nagyon kevés idő múlva el is tűnt az inkriminált szoftver letölthetősége.

Egyébként elgondolkoztam annó a koncepció egy kevésbé hivatalos formában való felelevenítésén is, de aztán hagytam az egészet a francba, nem hiányzott a balhé. Ha egyszer valamelyik spam eléggé fölidegesít, csinálok egy "proof of conceptet" a dologra.

( saynos | 2008. 07. 12., szo – 18:31 )

Igazabol nem kell ehhez botnet. Haver szimplan irt egy dotNET-es app-ot, amivel mondjuk spammelni is lehet, bar o nem ilyen celbol irta, hanem hirlevel ugyfeleknek, de a tesztelesnel remekul megerkezett authentikalt isp-s smtp-n keresztul 100 level nem egeszen 1 perc alatt.
Megvalami: ugyan most nem jut eszembe a neve, de regebben volt szo errol a "2-3 reject, es mondjuk a 4-re elfogadja a levelet" dologrol. Az is megoldas lehet.

Meg egy gondolat: A legjobb megoldas a digitalisan alairt level. Ha vegre atternenek az emberek a digitalis alairasra, akkor at lehetne allitani a szervereket, hogy csak digitalisan alairt leveleket fogadjon.

implementacio fuggo, lehet ugy is csinalni, hogy ne veszits vele rendes mta altal kuldott levelet. tipikusan a rossz megoldas, ha a teljes sender+recipient+clientip-t tarolod es ezzle hasonlitod a kovetkezo probalkozasokat, mert nagyobb isp-, freemail-ek tobb geppel dolgoznak, ezret valtozhat az ip, masreszt vannak olyan kuldo szolgaltatasok amik mindig valtoztatjak a sendert (backscatter szures miatt stb).

A'rpi

Pl. a postgrey-nek megmondhatod, hogy a kuldo IP-cimet vagy a C-osztalyu halozatcimet akarod eltarolni. Ha pedig a felado minden kuldesnel megvaltoztatja a MAIL FROM: utani cimet, en arra mondom, hogy "tipikusan rossz megoldas". Imho eleg a backscatter ellen, ha levelenkent egy random cimet allitasz be a MAIL FROM-ba, akarhanyszor is kelljen ujrakuldeni.

ASK Me No Questions, I'll Tell You No Lies

Akkor remelem, meg tudjak oldani, hogy egy levelet, ha masodjara is el kell kuldeni, akkor ne az adott C-n kivul levo hoszt akarjon elkuldeni. Btw. akar feherlistara (a szurkeere) is fel lehetne venni a gmail-t, de ez nem biztos, hogy jo otlet, mert jott mar azert spam abbol a halobol is....

ASK Me No Questions, I'll Tell You No Lies

2 apro rest latok a pajzson: a spammert semmi nem akadalyozza egy self signed certificate elkesziteseben, vagy b) csinal a thawte-nal egy teszt certificate-et (30 nap), amivel 4-5 kampanyt siman lezavarhat. Aztan csinalhat egy ujabb cert-et, ...

Masfelol szerinted hany smtp szerver kepes ellenorizni, hogy a levelben levo digitalis alairas koser-e?

A levelrol egyetlen modon lehet minden ketseget kizaroan eldonteni, hogy spam: a tartalma alapjan (a digitalis alairast most nem veszem ide), nem alkalmas* erre semmilyen lista (feher-, fekete- vagy szurke), sem a helo check, sem a captcha, csakis a tartalom.

*: ez nem azt jelenti, hogy teljesseggel hasznalhatatlanok ezek, ill. azt sem, hogy a tartalomszurok 100%-osak

ASK Me No Questions, I'll Tell You No Lies


A legjobb megoldas a digitalisan alairt level.

Ezt akkor mar valami komolyabban kene megoldani, mondjuk PKI+smart kartya. A kiallitonak ezzel el kellene szamolnia.
Ha spammelnek vele, keyt valtoztatni.
Sulyos penzeket fizetnie a tulajnak, ha spammelnek vele. (Elhagyas eseten 1 napon belul bekellene jelentenie az eltunest.)

Mondjuk automatikus riportolasok, monitorozasok szempontjabol rossz megoldas lenne. Weboldalakat kene atirni, stb.

( Aadaam v | 2008. 07. 13., v – 17:20 )

Picit off:

Emberektől (azon entitások köre, akik állítólag fel tudják oldani a captcha-t) marha kevés e-mailt kapok. Levelezőlistára esetleg.

Az e-mail forgalmam 90%-ban számítógéppel generált levél: spam, értesítő, stb.

Emberekkel IM-en és - egy bizonyos korosztályban - iwiwen kommunikálok, no meg turulcsiripen. Ja, és persze HUP fórumon :)

Szerintem a spam kérdés megoldva: IM-en azok a felhasználók tudnak nekem írni, akiket én visszaigazolok, a kapcsolati hálókon pedig egyszerűen a "jelentem" gomb miatt nem nagyon kerülhet be spammer. Néha van 1-2, de erőteljesen védekeznek ellene.

Beszélhetünk ennél jóval bonyolultabb hitelességvizsgálatokról (késleltetés, PKI, stb), de azt hiszem, ember az, akit a többi ember annak gondol (és fenn van az emberek közt -> iwiw/myvip/facebook...), vagy akinek én engedélyeztem, hogy irhasson (Jabber/MSN/egyéb IM)

Miért szükséges feltétele az aszinkron kommunikációnak (feladó, subject, dátum, body), hogy egy 1971-es protokollon történjen???

Akkor szerinted ne almodjak arrol, hogy enterprise instant messaging, hogy a blackberry a push e-maillel tulajdonkeppen egy mobilos IM?

(Ne szorakozzunk mar, cegek tucatjai elnek meg EIM-bol, en is ismerek parat, a multiknal az IBM SamePlace szinte kotelezo elem es akkor nem megfelelo uzleti felhasznalasra... 2003 ota gyakorlatilag minden munkahelyemen az IM volt A standard kommunikacios forma.)

Picit megyunk offtopicban, de en eddig ugy tudtam, e-mail nevterbol annyi van, amennyi domain (sot, resznevterek is vannak, tehat ha te pl. az ELTE caesar nevu gepen vagy, es olyat irsz, hogy user@ludens, akkor az a user@ludens.elte.hu cimre fog megerkezni)

Most itt nem mennek bele a data portability, friend connect, es egyeb technologiai reszletekbe, hogy hogyan szabvanyosodnak a kozossegi halok, de az URL-t mar lassan 20 eve kitalaltak ugyis, szoval tokmindegy.

Ami az en ertekezesemeben a point volt, es ez fuggetlen a cimterek szamatol: kommunikaciora megfeleloen sok csatorna van, mindig azt hasznaljuk, amiket ismerunk es alkalmasnak tunnek ra, es hogy a spam egy olyan problema, amit nem lehet hosszutavon technologiai eszkozokkel megoldani - helyette itt vannak ezek az emberalapu eszkozok, amik eleddig mukodnek.

( msandor v | 2008. 07. 15., k – 09:40 )

- nem használok semmilyen RBL alapú szűrőt, mert ne más mondja meg, hogy mi a SPAM, de az eredményeit pontra "váltom", és belekalkulálom a döntési fázisba (asszem Árpi is ezt írta)
- én is a tartalom szűrést preferálom, ahogy sj írta fentebb

így minimális a becsúszott SPAM-ek és a tévesen karanténezett levelek aránya, ami jobb is lehetne, ha minden user "igazolgatná" a saját leveleit, mert abból tanul a szűrő...

--
by Mikul@s

jobb is lehetne, ha minden user "igazolgatná" a saját leveleit, mert abból tanul a szűrő...

Ha a usereid elegedettek a jelenlegi pontossaggal, akkor ne tord magad. Legfeljebb ingereld oket azzal, hogy a te pontossagod egy keves tanitas/igazolas hatasara is mennyivel jobb :-)

ASK Me No Questions, I'll Tell You No Lies

nem használok semmilyen RBL alapú szűrőt, mert ne más mondja meg, hogy mi a SPAM,

Az RBL nem hülyeség mert megmondja, hogy egy internet szolgáltató előfizetői hálózatából (adsl pool) való IP címmel akar valaki (jellemzően egy felhasználó fertőzőtt vagy zombi gépe) levelet küldeni... és ebben az esetben hiába mutat rá dns bejegyzés akkor sem vesszük el a levelet. Így mentesül a szerver a levél átvizsgálása alól, erőforrásokat lehet spórolni.

--
maszili

pedig jol csinalja msandor, mert o - veled ellentetben - nem fog fals pozitiv hibat veteni. Az rbl-eken azert eleg sok legitim levelezo is fennakad, ugyanis hibas az az elofelteves, hogy az csak "adsl pool", amiben (ugyis csak a) zombik vannak. Arrol nem is beszelve, hogy mit csinalsz azzal a web szerverrel, amin van 2 site, 2 kulonbozo ugyfele, es az egyik spammel? Ha elutasitod a leveleit, az sem jo, ha beengeded, az sem. Az rbl-ek ezt a szituaciot nem kepesek helyesen kezelni, mert szerintuk a vilag vagy feher vagy fekete, azonban az IP-cimek _a_valosagban_ a szurke valamilyen arnyalatat veszik fel.

Ha eleg bator vagy, es szerinted az jo, ha mas valaki mondja meg, hogy melyik levelet veheted at, es melyiket nem, akkor probald csak ki az uceprotect-et. Sok sikert hozza, mert nagyon "meg fogja sporolni az eroforrasaidat". Ezek a tokeletlenek ui. egesz ISP halozatokat blokkolnak. Nem C-osztalyu cimeket (pedig az is durva), hanem AS-eket.

Mondom, lehet rbl-eket is hasznalni, csak okosan. Ha pusztan egy rbl alapjan eldobsz egy levelet, akkor csak ido kerdese, hogy a baj utolerjen. Hacsak nem 100-as a feketelistad...

ASK Me No Questions, I'll Tell You No Lies

pedig jol csinalja msandor, mert o - veled ellentetben - nem fog fals pozitiv hibat veteni.

Nem tudom hogy Sándor pontosan hogyan csinálja de tudomásom szerint nincs tökéletes megoldás. Egy számítógép sohasem fogja tudni eldönteni egy levélről 100% pontossággal hogy az szemét vagy sem.

ugyanis hibas az az elofelteves, hogy az csak "adsl pool", amiben (ugyis csak a) zombik vannak

Nekem ne küldjön olyan "szerver" levelet ami egy előfizetői hálózatból való IP _címmel_ jön. Az én feltevésem az, hogy aki MTA-t üzemeltet az nem egy ADSL kapcsolat mögött fogja üzemeltetni a szerverét. Ha mégis olyan elvetemült akkor meg vegye a fáradtságot és állítsa be relay-nek a szolgáltató MTA-ját és akkor nem lesz kiszűrve.

Arrol nem is beszelve, hogy mit csinalsz azzal a web szerverrel, amin van 2 site, 2 kulonbozo ugyfele, es az egyik spammel?

Ilyen esetekben nem az IP van vizsgálva hanem a domain. Így meg lehet különböztetni a két esetet.

--
maszili

tudomásom szerint nincs tökéletes megoldás.

Igaz, de az elerheto megoldasok kozott azert vannak kulonbsegek. Az elsodleges cel ma mar nem a minel nagyobb spam felismeres, hanem a fals pozitiv hibak minimalizalasa, ill. annak az elerese, hogy jo level ne vesszen el. Ez utobbira az rbl keptelen.

egy előfizetői hálózatból való IP _címmel_

Mar miert kellene mindenkinek egy isp smtp szerveret hasznalnia? De ha ez jobban tetszik, akkor adsl pool helyett vegyunk egy colocation cimtartomanyt. Ha en tennek egy gepet colocation-be, nekem ugyan nem kellene az isp mail szervere, magam akarnam a levelezesem intezni, es ezzel aligha vagyok egyedul.

Ilyen esetekben nem az IP van vizsgálva hanem a domain. Így meg lehet különböztetni a két esetet.

Honnan tudod, hogy melyik az "ilyen eset"? Hiszen az rbl - altalaban - smtp idoben szur, azaz fogalmad sem lehet, hogy melyik esettel lenne dolgod, ha tovabbengedned...

ASK Me No Questions, I'll Tell You No Lies