Sender ID: a csúfos vég

Spam

Az internetes szabványokat elfogadó szervezet, az Internet Engineering Task Force (IETF) elutasította a Microsoft Sender ID nevű szabványjavaslatát.

( bra | 2004. 09. 14., k – 15:22 )

Bill: Gizike, legyen szíves belépni az OTP házibankba és átutalni 1 millió dollárt az IETF számlájára. Köszönöm.

( x15 v | 2004. 09. 14., k – 15:23 )

Hö :-)

Mert az elemzok ugye - mar megint.

Ugy latszik az Apache es a Debian sokat myomott a latban.

( whitehawk v | 2004. 09. 14., k – 16:15 )

HÁHÁHÁHÁHÁHÁHÁHÁ ;)))))))))))))))))))))))))))))))))))))))))))))))))))

( KoS | 2004. 09. 14., k – 16:19 )

En azert me'g nem merek orulni...

Ha az elso hozzaszolonak igaza lesz, akkor me'g csalodhatunk :(

( sas | 2004. 09. 14., k – 17:06 )

Nem azért, de rátok van bármilyen hatása a spammelők felesleges leveleinek?

Rám nem.

Miért?

Egyrészt rendkívül kevés w$-os emberrel levelezek, így ritkán válik a címem zombigépek áldozatáva. Tömören: mivel nem levelezek w$-osokkal alig kapok spamet.

Másrészt, ha kapok nem kerül a szemem elé, hiszen mint legbutább felhasználó is gyerekjáték oly levelezőt használnom, ami eleve megadja, hogy szinte kizárólag csak a lényeges levelek kerüljenek elém.

Az a havi néhány, ami néha átcsúszik ezen, meg már igazán nem zavar, vírusom nem lesz tőle, és egy mozdulattal letörölhetem még ezeket is.

Na erre kellene felhívni az emberek figyelmét.

Hiaba nem levelezik az ember windowsosokkal, ha az email cime kint van a neten, a spamrobotok levadasszak.

Napi ~1-1.2k spamet fog meg a szurom, 10-12 jut at. Ha ram nincs is nagy hatassal, a savszelessegembol akkor is eszik az a napi ezer extra level (tobbsegeben nem is kicsik, hanem html stuff mindenfele grafikaval meg szirszarral, vagy nem is spam hanem virus, ami megnagyobb tud lenni).

( nevergone v | 2004. 09. 14., k – 19:46 )

Az Internet nem egy adott csoporté.

Hanem mindenkié.

Csak olyan megoldások győzhetnek, amelyek mindenki számára nyíltak, szabadon hozzáférhetőek és implementálhatóak.

Remélem ez így is marad...

ne csak saját magadból indulj ki. ez erősen mennyiség kérdése. ha egy vállalat mail címei kerülnek fel spammerek listáira, akkor már egész más a helyzet. nekünk pl. nemrég be kellett szigorítani a mail fogadásunkat, mert naponta kb. 50 000 spam/vírus ömlött be a mailszerverünkre, amit egész egyszerűen nem bírt normálisan feldolgozni.

(igen, van központi spamszűrő, amit tanítunk. nem, az sem old meg minden gondot)

aztán még ott van az probléma, hogy a spamszűrő néhány esetben téved és egy-egy fontos levelet is spamnek ítél, tehát tökéletesen nem lehet elkerülni, hogy a spameken is ellenőrzésképp átfusson, aki kapja.

Vegyünk mondjuk egy céget, ahol 1000 ember dolgozik gépen. Mondjuk (kül)kereskedelem és support is van terítéken, így az idegen címről, vagy nyelven érkező levelek nem törölhetők automatikusan.

Mondjuk egy levélről eldönteni a fentiek miatt 5 mp, hogy spam -e. Mondjuk mind az 1000 ember kap naponta egy tucat spam-et.

12x5mp = 1 perc

1000 ember esetében: 1000 perc = 16,66 óra

mondjuk legyen egy 250 ezres bruttó fizetés / hó átlagban (ebben benne van a 80 ezres adatrögzítő és a pár db millkós felső vezető is), azaz 1562,5 Ft-os bruttó órabér, amire rájön a munkáltató által fizetett járulék, ez most kb. meg másfélszerezi a költséget: 2343,75 órabér.

Vagyis: 16,66x2342,75 = 39046,875 költség naponta.

Ez évente (240 munkanappal számolva): 9 371 250 Ft.

Ezt továbbvíve gondoljunk bele a nyugati 3-4x-es fizetésekbe.

És akkor nem számoltuk, hogy a napi 12 000, főleg HTML levél sok-sok mega is lehet adatforgalomban, valamint, hogy a belső rendszernek fel kell dolgoznia, stb.....

Nincs igazad. A spam az interneten manapság nagyon nagy probléma. Mindenki kénytelen spam filtereket működtetni. Te éppen lokálisan végzed ezt, de van, ahol a levelező rendszer pontozza a leveleket. Tehát a rendszer fenntartóinak kerül hardver és emberi erőforrásába (ez de csúnya szó...) az, hogy a spammer küldi a leveleit. Ergo a spammer (közvetve vagy közvetlenül) a _címzettek_ költségén spammel. Ez felháborítóan aljas dolog.

Nagy probléma még a false positive-ok réme is. A spam mellékhatása például, hogy attól kell félned, hogy nem kapsz meg bizonyos leveleket...

Ki nem állhatom a spameket.

Üdv.

HSRP-re nincs free implementáció?

Hmm... Érdekes, mert épp ma teszteltünk HSRP-vel összelőtt routerpárost, és közben linuxon figyelt a tcpdump, és mindent elmondott a HSRP csomagokról. És még csak nem is kellett "durva" módon hallgatózni. Elég volt neki abban a VLAN-ban lennie egy access porton, amely vlan-on HSRP is volt.

Vagy ennyire könnyű lenne dekódolni a HSRP üzeneteket, és az implementációja meg ennyivel bonyolultabb lenne?

Amit eddig olvastam róla, az alapján nem tűnt egy nagy etwasnak.

VRRP-t már párszor emleteted, de mindig elfelejtem, hogy mire jó :-)

EIGRP... Hmm... és ahhoz mit szólsz, hogy némi átgondolt tervezés és OSPF? :-)

ISL... Na felejts el! Annyira ritka ***** valamit már rég láttam! Ott a .1q! Aki ISL-t akar használni az meg is érdemli! :-)

De ha olyan frankó, akkor légyszi küldj nekem idevágó részleteket running-config-ból ahol egyik oldalon a változatosság kedvéért egy 3550 van a másik oldalon meg egy 6509... Ha a c6k-ban hibrid image futott... befürödtem... És hallottam már nálam okosabbakat ugyanennél a párosításnál befürödni ahol a c6k-ban meg standard ios image futott...

Szóóóóval... Minek is az ISL?

Főleg, hogy pl. .1q-nál akár olyat is játszhatsz, hogy ha akarod, hogy ugyanarra a médiára taggelt és taggeletlen forgalmat is zavarj :-) Ha jól tudom, akkor ISL ezt nem tudja...