Spam

A The Moscow News oldal szerint Vardan Kushnir-t, a 35 éves orosz SPAM királyt, tegnap holtan találták moszkvai apartmanjában. A spammer a fejére mért sorozatos ütésekbe halt bele.Kushnir vezette a Center for American English, a New York English Centre és a Centre for Spoken English műintézményeket, amelyek agresszív internetes hirdetési kapmányokat folytattak napi millió email világgá küldésével.

Feldühödött internet felhasználók korábban támadták az American Language Centert közzétéve az interneten annak telefonszámait, hívásokat provokálva (úgy hirdették a center számait, mint kontakt számok olcsó szex szolgáltatásokhoz).

Valakinek elfogyott a cérnája?

A teljes cikk itt.

A Blue Security névre hallgató izraeli cég egy olyan rendszert állított üzembe, amellyel a spamot küldözgető weboldalakat torpedózza meg több ezer válaszlevéllel. A stratégia: a spam-ot küldözgető pornót, pirulákat, hímtag-hosszabbító kézi készülékeket ajánló weboldalak on-line megrendelő formjait elárasztják válaszlevelekkel, amelyben azokról a termékekről érdeklődnek, amelyeket a spammer a levélben hirdetett.

A technikát több anti-spam szervezet is kritizálta.Eran Reshef, a Blue Security alapítója és vezetője szerint az elmúlt négy öt évben passzív anti-spam technikákat használtak, amelyek nem vezettek eredményre.

A cégnél történt regisztrálás után az monitorozza a felhasználók email-jeit, megállapítja, hogy a spam-hoz melyik reklámozó on-line weboldal tartozik, majd annak megrendelő formjait elárasztja válaszlevelekkel.

A cég vezetője szerint a spammerek azzal, hogy spamot küldtek, felkérték az áldozatot a válaszra. Az nem tett mást, mint válaszolt. A Blue Security reméli, hogy ez akadályozni fogja az ilyen oldalak munkáját, és a spammelést drágábbá és sokkal munkaigényesebbé teszi.

A BBC cikke itt.

A Slashdot egyik cikke szeint az IESG (az IETF jóváhagyó bizottsága) ideiglenesen elfogadta az SPF-et és a Sender-ID-t (korábbi cikkünk), mint kísérleti szabványokat.Az elfogadásra utalnak bizonyos bejegyzések az IEFT adatbázisában itt és itt. A Slashdot cikk itt.

"A Microsoft MSN és Hotmail novembertől már levélszemétként fogja azonosítja azokat az e-maileket, amelyek nem tartalmazzák a "Sender ID"-t, vagyis a küldő azonosítóját."

A Microsoft tegnap sajtóközleményben bejelentette, hogy átdolgozta a Sender ID (korábbi cikkünk) névre hallgató javaslatát, s ismét elküldte a már átdolgozott verziót az IETF-nek.

A bejelentésről, és a Sender ID javaslatot tervező csapat főnökével készített az interjút itt olvashatjátok.

Pár hónappal ezelőtt volt szó itt a HUP-on a Microsoft-féle SPAM ellenes javaslatról, a Sender ID-ről. Akkor megbeszéltük a javaslat hátulütőit, és abban maradtunk, hogy sokat nem ér a SPAM ellenes harcban. Közben úgy tűnik, hogy az IEFT is elállt attól, hogy az MS javaslatból szabványt készítsen.

De ha nincs Sender ID, akkor mi lesz? Abban mindenki egyetért, hogy a SPAM helyzetet meg kell oldani, és erre az SMTP protokoll önmagában nem képes. A Yahoo! is elgondolkodott, hogy mit lehetne tenni a levélszemetet okádó patkányok ellen, és megszületett a DomainKeys névre hallgató elgondolás. Nézzük mi ez:Az email spoofing - mikor valakinek a nevében küldünk kéretlen levelet (SPAM) azért, hogy a címzett látva az ismert feladót megnyissa és elolvassa a szemetet - nagy probléma. A feladó authentikálása, azonosítása és visszakövethetősége nélkül soha nem lehetünk biztosak abban, hogy valóban az küldte nekünk a levelet, aki a feladó mezőben szerepel (nem ritka, hogy saját magunktól kapunk reklám levelet).

A Yahoo! által javasolt DomainKeys a feladó azonosítását hivatott elvégezni.

(c) Yahoo! Inc.

2.) Aláírás: Minden olyan esetben, amikor a domainben levő jogosult felhasználó levelet küld a DomainKeys-t tudó mail szerveren keresztül, akkor az összes levele alá lesz írva a mail szerver rendelkezésére bocsátott privát kulccsal. A kulcs el lesz küldve (a szerver beilleszt egy DomainKey-Signature headert) a levéllel együtt a címzett mail szerverének. (ábra ``B'' rész)

Hogyan működik (fogadó szerver)?

1.) Felkészülés: A Domainkeys-t tudó, fogadó szerver kiveszi az aláírást a levélből, és a DNS szerverben levő publikus kulcsot ``leszedi''. (ábra ``C'' része)

2.) Ellenőrzés: A már birtokában levő publikus kulcs alapján leellenőrzi a küldő hitelességét.

3.) Kézbesítés: Az ellenőrzés végkimenetelétől függően a mail szerver érvénybe lépteti a helyi házirendet, és annak megfelelőlen jár el (vagy kézbesíti a levelet, vagy eldobja, stb.). (ábra ``D'' része)

A DomainKeys draft-ját megtalálod itt. Az Yahoo! szeretné, ha a Domainkeys az IETF által elfogadott szabvánnyá válna.

Bővebb infó itt.



(A linkért köszönet LiRul-nak.)

Az Eweek szerint az IETF (Internet Engineering Task Force) feloszlatta a MARID munkacsoportot. A MARID (MTA Authorization Records In DNS) (Google cache, az eredeti oldalt törölték) csoport azon dolgozott, hogy egy olyan mail authentikációs szabványt alkosson meg, amellyel hatékonyan fel lehet venni a küzdelmet a SPAMmerek ellen.Az IETF szerint a csoport azért került feloszlatásra, mert a csoport tárgyalásai során alapvető kérdésekben nem születtek megegyezések.

A MARID volt az IETF azon csoportja, amely úgy döntött pár napja, hogy elutasítja a Microsoft-féle Sender ID szabvány-javaslatot.

Az Eweek cikke itt.

Megjelent a népszerű, SpamAssassin névre hallgató levélszemét-szűrő 3.0-ás verziója. Az anyag letölthető innen. Az új kiadáshoz új logó is jár. - írja a Slashdot.

Az America OnLine (AOL) nem támogatja a Microsoft-féle Sender ID-t. Ezt a cég csütörtökön jelentette be a ZDNet szerint. Egy hosszabb és pontosabb összefoglaló a dologról az internetnews.com oldalain itt.

A közelmúltban sok helyen, köztük a HUP-on is megjelent a hír, hogy az IETF elutasította a Microsoft szabványosítási kérelmét a Sender ID-ra vonatkozólag, ezért a Sender ID-nak vége.A NewsForge utánajárt a kérdésnek, és megállapította, hogy ez azért nem teljesen így van.



Megkérdezték Meng Weng Wong-ot, az SPF atyját, Yakov Shafranovich-ot, aki tagja az Anti-Spam Research Group-nak, amely szintén dolgozott az SPF tervezetén, mielőtt az IETF elé került jóváhagyásra, illetve Andrew Newton-t, aki tagja az IETF azon munkacsoportjának (ha jól értettem), amelyik elutasította a Microsoft tervezetét.

Egyikük sem minősítette halott ügynek a Sender ID-t, Andrew Newton pedig azt mondta, "a Sender ID ügye még megfontolás alatt van, és a munkacsoport még dolgozik néhány specifikáción, hogy a hálózatüzemeltetők választhassanak, miként akarják alkalmazni a Sender ID-t.

(Hogy ez mit jelent...?)