Mi az a Sender ID, és mi a probléma vele?

Címkék

A napokban tele volt a nemzetközi sajtó a Sender ID-ról szóló cikkekkel. Gyorsan nézzük meg, hogy mi is ez, és hogy mi a probléma vele. Sajnos közvetve érint minden Internetet aktívan használó (levelező) felhasználót és adminisztrátort is...

A SPAM (kéretlen levél) nagy probléma. A SPAMmerek újabban azzal a módszerrel küldenek kéretlen levelet, hogy meghamisítják a feladót, így gyakran előfordul, hogy az ember fia olyan levelet kap, amelyben saját magát felszólítja arra, hogy vegyen saját magától Penis Enlargement Set-et, mert az milyen jó... A hamisított feladóval jövő levelek kellemetlen helyzetbe hozhatják azt, akinek a nevében a levelet küldték, hiszen nem mindenki olyan képzett, hogy rájöjjön arra, hogy a levél tulajdonképpen nem attól származik, aki a feladó
mezőben szerepel.

A SPAM olyan probléma, amely rengeteg embert érint. A jelenlegi megoldások sajnos nem nyújtnak ellene kellő védelmet. Többen dolgoznak olyan megoldáson, amely hatékony védelmet nyújthat a SPAMok ellen. Jelenleg is több SPAM-ellenes technológiát leíró dokumentáció fekszik az IETF (Internet Engineering Task Force - az Internet megfelelő működéséért felelős szerverzet) előtt véleményezés céljából.

Az új technikák már nem a SPAM levelek tartalmát vizsgálják, sokkal inkább a küldőt authentikálják. Mivel a legtöbb SPAM hamisított email címről jön, fontos, hogy azonosítani tudjuk a küldő személyt. Erre jó a Sender ID.

Lássuk mit tettek ennek érdekében az elmúlt időkben, hogy jön a képbe a Microsoft, és mi az ami a szabad szoftveres fejlesztőket aggasztja:- 1998-ban Jim Miller egy levelet küldött Paul Vixie-nek, amelyben felvázolt egy egyszerű technikát, amellyel el lehet dobni a hamisított leveleket

- 2002-ben Vixie publikálta a Repudiating Mail-From protokoll munkáját, amely Miller ötletén alapult

- A Mail-From két újabb munkát inspirált: az egyik a Hadmut Danisch-féle "Reverse MX", a másik pedig a Gordon Fecyk-féle "Designated Mailer Protocol" (DMP)

- 2003-ban Meng Weng Wong felhasználva a Reverse MX és a DMP legjobb funkcióit megalkotta a Sender Policy Framework-öt (SPF), amely rövid időn belül a legnépszerűbb DNS-alapú anti-spam eszközzé vált

- Az átalakulás folytatódott, a Microsoft fogta a Caller ID névre hallgató javaslatát, beburkolta vele az SPF-et, hozzáadott egy harmadik specifikációt, a Submitter Optimization-t, és megszületett a Sender ID

A működés röviden: Az SPF / Sender ID használatához módosítani kell a DNS bejegyzéseket és a levelező szervereket (Mail Transfer Agent-eket - MTA). A DNS módosítás egy újabb bejegyzést (record) takar. A bejegyzés azonosítja az(oka)t a gépe(ke)t, amelyek jogosultak arra, hogy egy megadott domainben levelet küldjenek. Természetesen módosítani kell a levelező szervereket is (Sendmail, Postfix, Exim, stb.), hogy képesek legyenek kezelni ezt a bejegyzést, azaz képesek legyenek eldönteni, hogy a hozzájuk érkezett levél hamisított-e vagy sem. Magyarul, hogy a levél küldője jogosult-e arra, hogy a domainből levelet küldjön.



(c) Microsoft Corporation





1.) A küldő elküldi a levelét a címzetthez

2.) A címzett mail szervere megkapja a mailt

3.) A címzett mail szervere ellenőrzi a küldő domain-jének SPF bejegyzését a DNS-ben

4.) A címzett mail szervere eldönti, hogy a küldő email szerverének IP címe azonos-e a DNS-ben bejegyzett és publikált IP címmel

A Microsoft a napokban kiadta a Sender ID új, jogdíj mentes licencét és egy FAQ-t. A licenc használatához egy szerződést kell aláírni a Microsoft-tal. Sajnos a licenc olyan, hogy kérdéses a kompatibilitása az Open Source Definition-nel, a Free Software Definition-nel, a Debian Free Software Guidelines-szal, és a GPL/LGPL licencekkel.

Eric Allman - a Sendmail Inc. vezérigazgatója - bejelentette, hogy a Sendmail jelenleg felfüggesztette a Sender ID implementálását. Ennek az oka az, hogy a Microsoft olyan licencet erőltet, amely elfogadhatatlan a szabad szoftveres fejlesztők számára. Ennek ellenére nem zárkóznak el az implementálásától:

Sendmail, Inc. has worked with Microsoft to help them produce a patent license that will be acceptable for ourselves, the IETF, and the open source community at large. This message summarizes our position. The following discussion refers to the Royalty Free Sender ID Patent License (RFSIPL), dated 23 August. Harry has already posted it to the list, although it will take a few days to appear on the Microsoft Web site.

The executive summary is that we believe that the Sender ID technology is promising, and will hopefully be adopted. We believe that although not ideal, the RFSIPL and associated IP disclosures satisfy the IPR requirements of the IETF and are compatible with most major open source licenses. It would be extremely disappointing if this potentially useful technology to combat fraud and spam failed for reasons unrelated to its technological merits.

The revisions in the RFSIPL have clarified several important issues. Notably, it is now explicit that recipients of a Sender ID implementation who do not intend to redistribute the code do not need to get a patent license to use such an implementation. However, the license is not without restrictions.


Richard Stallman is kifejtette véleményét a Sender ID-vel kapcsolatban az IETF levelezési listán:

Microsoft's Sender-ID license is directly incompatible with free software, regardless of which free software license is used. Free software means users are free to run it, study and modify the source, and to redistribute it with or without changes. Free to do so means there is no requirement to ask or tell anyone that you are doing so.

The Microsoft license for Sender-ID directly forbids release of software with all these freedoms, so it is impossible for any program to be free software under Microsoft's regime.

I've been expecting to see something like this ever since Gates started talking about spam. This license is an example of Microsoft's strategy for killing off free software as an alternative to Windows. Microsoft first patents something, then incorporates it into a format or protocol, then tries to make it de rigueur while excluding those it wishes to exclude. In the absence of resistance, Microsoft has a good chance of imposing whatever standards it likes. Let us, therefore, resist it here and now.


Egyelőre itt tart az ügy. A Microsoft ígéretet tett arra, hogy átdolgozza a licencet, közben Theo de Raadt már azon aggódik, hogy a Sendmail elképzelhető, hogy nem lesz annyira szabad, mint eddig (köszönhetően a licencnek).

Két lehetséges út látszik (abban az esetben, ha az IETF elfogadja a Microsoft javaslatát). Vagy implementálja egy szoftver a Sender ID-t, vagy nem. Ha igen, akkor el kell fogadnia a MS licencét, amely jelenleg több szakember szerint is inkompatibilis a szabad szoftveres licencekkel. A másik út, hogy nem implementálja, viszont akkor könnyen megeshet, hogy a használója pár éven belül már nem fog levelezni senkivel...

Hasznos linkek:

Sender ID Framework
New Email Sender ID license debate sure to continue

Email Sender ID: The hype and the reality

MS Releases License For Sender-ID

Trouble brewing in the land of smtp

Microsoft and Meng Wong to Merge Caller ID for E-Mail and SPF Anti-Spam Technology Proposals

Hozzászólások

Az axelero mar regota spamelo domainkent volt feltuntetve az egyik spam adatbazisban a nehany kozul - csak lehetetlen az ottani adminisztratorokkal szot erteni (nem kezdik megkeresni a spammereket a halozatukon), ezert nem veszik ki onnet oket. Ez mar tobb eve teny. Csak ido kerdese volt mikor szigorit be valaki annyira, hogy szorni kezdi az onnet erkezo leveleket a devnullba

Remelem, nem olyan nezopontot mondok, ami senkinek sem merult fel eddig: Hagyjuk a francba az email-t! K***ra regi, k***ra ocska, foldozgatott protokollokkal mukodik, csoda, hogy eddig huzta. A megoldas szerintem valamilyen p2p-jellegu dolog; mert ugye az ICQ-n is lehet levelezni es fajlokat is cserelni, es a felhasznalot mit erdekli, hogy emogott milyen protokoll van? MEG MOST kell gyorsan egy uj otlet, egy olyan szoftver, ami robbanasszeruen elterjed es feleslegesse teszi az eddigi levelezoprogramokat, de azokhoz nagyon hasonlo feluletet ad. Igy a levelezokliens es -szerver fejlesztok nem maradnanak munka nelkul, csak az elgondolas, a mukodes lenne mas. (Mar latom a valaszokat, hogy mondjam az otleteimet, meg hogy ez hogyan fogja a spam-meloket megallitani. Sajnos en nem vagyok olyan zseni, hogy ilyet kitalaljak, de ha lesz ilyen, melle fogok allni)

G.

Nem! A Tisztelt Urak kifejlesztettek egy protokollt, minden buktatojaval egyutt. A Microsoft ezt szepen vegigvarta, majd lenyulta az egeszet. Es tehette mindezt azert, mert a GPL licensz semmi ellen nem ved. Ertsetek mar meg, hogy a GPL nem vezet sehova - es nem arrol beszelek, hogy penzert kell adni a szoftvereket. Kerdezzetek meg Gereoffy Arpit, hogy mit mond errol...

G.

A tisztelt Urak evekig vakaroztak, ekozben a Microsoft letett valamit az asztalra. Nem az elso eset.

Hát mé nem fejlesztenek ki a szabad programozók is egyet maguknak, azt kész? A mikroszoftosok leveleznének a mikroszoftosokkal, a többiek meg egymással. Mé kötelező az MS cuccait használni?

Hat hogy a MS az azert tulzas, inkabb Meng Meng, aki meglehetosen szoros baratsagot apol az MS-sel. De valoban, kell mar valami megoldas a SPAMmer patkanyok ellen. Remelem az MS hajlando lesz atdolgozni a licencet (igerte, hogy igen), es akkor ezzel mindenki csak nyerhet.

>akkor könnyen megeshet, hogy a használója pár éven belül már nem fog levelezni senkivel...

Acsi. Ez igy nem igaz. Mert:

1. ha az illeto kuldi a levelet, akkor mind1, hogy a MTA-ja ismeri-e, mivel csak a fogado reszt kell modositani.

2. ha fogado levelet, es nem implelentalja, akkor minden levelet elfogad, egyet sem dob ki.

tehat tud mailozni. Nem lesz vedve a spamoktol, e tud mailezni.

Ami viszont ettol fuggetlen, a DNS bejegyzes modositasa.

En azt tartom aggalyosnak, hogy szabvanykent fogad el a vilag olyan dolgot, ami 1-etlen ceg/ember szellemi tulajdona. Az illeto/ceg azt csinal amit akar a szellemi tulajdonaval. Barmely pillanatban barmire valtoztathatja a licenszet.

extrem esetben azt modja, hogy igaz, hogy eddig ingyenes volt, de holnaptol mindenki napi 10...0Ft-ot fizessen.

Akar dijat szedhetne a PDA-soktol minden egyes dupla kattintasra;-)

***** vilagban elunk, ahol ilyen dolgok megtortenhetnek.

A levelezo kliensnek is tudnia kell a Sender ID-t. Ha te olyan szerveren levo mailboxba akarsz majd levelet kuldeni, amely csak Sender ID-s levelet fogad el, es te nem kuldesz Sender ID-t, akkor el lesz dobva a leveled. Ha a fel vilaggal majd nem tusz levelezni, az vidam lesz.

Idezet a Microsoft.com-rol:

(http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx

Steps for Mail Senders and Developers

``If you are an e-mail sender, you simply need to create an SPF text record and insert it into the DNS records of your outbound e-mail server(s). For a step-by-step walkthrough, just enter your domain into the Sender ID Framework SPF Record Wizard (anti-spamtools.org).''

Az átalakulás folytatódott, a Microsoft fogta a Caller ID névre hallgató javaslatát, beburkolta vele az SPF-et, hozzáadott egy harmadik specifikációt, a Submitter Optimization-t, és megszületett a Sender ID

ha jol értem a spf et bővitette ki az ms nem

az spf az gpl es nem?

akkor mi az hogy a sender id meg másik licenset használ

ez kb olyan mintha letöltöm a kernelt átirom a fejléceket meg hozzáadok egy kernelhivást és hopp eladom jo pénzért

ez a gpl gátolja

akkor a sender id hogy lehet elbára épített liseces ????

Egyelore ez meg csak egy vázlat (draft), javaslat, de az IETF ezt szeretne szabvanynak. El kell meg ahhoz fogadni, es az kell hozza, hogy mindenki hasznalja, mert kulonben nem sok ertelme van. En remelem, hogy sikerul egy olyan licencet talalni hozza, ami jo mindenkinek.

Tobbe kevesbe ide tartozik szerintem a levelezo fergek elleni vedelem is es kovezzetek meg, de en meg mindig azt mondom, hogy a megoldas az lesz, amikor vegre eljon a nagytomegu, olcso, digitalis alairas kora, amikor mindenkinek lehet minden mail cimehez digi alairasa, ami nem jar le 4-5 evnel hamarabb.

Ekkorra fel kellene kesziteni az smtp szervereket arra, hogy

a) ne fogadjanak el alairas nelkuli leveleket

b) az alairtakat tudjak ellenorizni (sok-sok CA tukor szerte a vilagban)

Ezzel meg lehetne fogni a hamis feladoju leveleket (fergek), illetve vissza lehetne vonni a spammerek digi alairasait, ekkor pedig az a) eset lep eletbe.

Ehhez az kell, hogy legyen sok trusted CA szerver, amiket az smtp szerverek folyton maceralhatnak. Ez persze komoly penz, de sztem a spam es a terjedok fergek okozta kar meg nagyobb.

mogorva

Én nem így látom:

http://download.microsoft.com/download/d/a/2/da2821f5-6acb-4058-8974-5a3c7d187794/senderid.pdf

6.4 neutral A "neutral" result from the check

means that the domain can offer no information about whether the message was authorized. An SMTP server receiving this result SHOULD NOT reject the message for

this reason alone, but MAY subject the message to heightened scrutiny by other anti-spam measures, and MAY reject the message as a result of this heightened scrutiny.

Szerintem ez NEM OLDJA MEG A PROBLÉMÁT.

Mi ellen véd? az ellen hogy valaki trey at hup!hu -nak mondja magát (illetve hogy hup.hu-nak mondja magát mert más a hup.hu-ról mondhatja azt hogy trey vagyok)

És mi van ha valaki a ez-egy-spammre-letrehozott-domain-egy-heting-spammelek-innen.com -ról küld levelet?? semmi ugyanúgy megérkezik a levél.

Valaki világosítson már fel hogy miben több ez mint az SPF? (nincs kedvem az egészet végigolvasni)

A másik hogy XML recordokkal megerőszakolni egy DNS szervert fújj!

Az ilyen találmányok csak tönkreteszik a meglévő működő infrastruktúrát, de a valódi problémát nem oldják meg.


És mi van ha a hup.hu-ról kapott levelet .forward-dal továbbküldöm? akkor azt mondja a forwardoló gépnek hogy "nem, te nem vagy a hup.hu"?

ja és persze a bounce-ok sem működnek (az SPF-ben).

Az SPF az GPL, ami copyright, a SenderID meg szoftverszabadalom!

Az SPF _copyright_ licence a GPL, tehát az magára egy konkrét megvalósításra vonatkozik nem pedig a működési elvére. Ellenben a SenderID magát a működési elvet védi. Az SPF-et újraimplementálhatod from scratch, és akkor már nem gpl. A SenderID-t akárhogyan is implemetálod AZÉRT A MICROSOPS PÉNZT KÉRHET!

http://www.newsforge.com/software/04/02/26/1448253.shtml

Attol fugg, hogy mennyire szigoru egy adott ceg spam policy-ja. Azt tudtad, hogy Olaszorszagba mar most is meglehetosen nehez levelet kuldeni bizonyos cegekhez? Hogy miert? Mert az Axelero spamhostnak van minositve.

Ha a Sender ID-t elfogadja az IETF es szabvany lesz, akkor elhiheted, hogy sok ceg fogja hasznalni. Ebben az esetben elkepzelheto, hogy ha te nem hasznalod, akkor a leveleid SPAM-kent mennek a /dev/null-ba. Ez az egyik problema a Sender ID-vel (persze IMHO).

A masik az, hogy az MTA-kat fejlesztok neki is alltak mar implementalni, es olyan hirek is jottek, hogy emiatt a Sendmail lincence megvaltozhat. Van is kinn valami draft az uj licencrol. Az uj licenc olyan, hogy elkepzelheto, hogy az OpenBSD-bol ki is ugrik mindjart a Sendmail.

>És mi van ha valaki a ez-egy-spammre-letrehozott-domain-egy-heting-spammelek-innen.com -ról küld levelet?? semmi ugyanúgy megérkezik a levél.

Nem erted. Ha mindenki hasznalja a Sender ID-t (nem en mondom, hanem ez az elkepzeles, de az is lehet, hogy en ertem felre), akkor egyertelmuen azonosithato, hogy en en vagyok. Ha te letrehozol egy spam domain-t, akkor teged bizony sittre vagnak. Hogy miert? Mert te jegyezted be a domaint. Megkeresheto vagy.

Nezzuk (szerintem) mi lenne ilyenkor. Hasznalja mindenki a Sender ID-t. Te csinalsz egy spam domaint, es vigan szorod a vilagot. Ha hasznalod a Sender ID-t, es kozben spam-melsz, akkor nincs mentseg, mesz a sittre (sajat magad azonositod). Ha nem hasznalod, akkor a leveleid nagy valoszinuseggel SPAM-kent fogjak vegezni. En igy latom.

"Magyarul, hogy a levél küldője jogosult-e arra, hogy a domainből levelet küldjön. "

arra leszek kivancsi, hogy azon home userek akik DHCP mogott vannak vajon hogyan fognak sajat domainukbol levelet kuldeni.

Vagy hulyeseget kerdezek?

Szerintem lassan ideje lenne atgondolni bizonyos protokollokat (smtp, pop3), es ami nem OK, azt vagy biztonsagossa tenni, vagy kidobni a frandba.

Eddig jok voltak, de eldurvult a vilag, most mar nem lehet plain-text jelszavakkal rohangaszni a vilagban (pl. pop3, telnet, stb.)

mogorva

Ezzel latok egy kis gubancot. Tfh. van egy szolgaltato, aki nyujt levelezest boldog-boldogtalannak (freemail, mailbox, stb.). Az ugyfeleinek a kimeno levelei a szolgaltato SenderID-javal mennek ki, mert pl. nem smtp-t nyujt, hanem webmail-t. A szolgaltato alairat az emberekkel olyat, hogy o csak tovabbit, a tartalomert nem felelos, innentol bentrol barki spammel, ha a szolgaltatot nem zavarja, menni fog. (A posta sem felelos azert, ha en feladok x ezer levelet.) Innentol a spammernek annyit kell tennie, hogy alapit egy (kamu) szolgaltato ceget, beregisztral domain-t, spammel mint aalat, aztan szettarja kezeit, hogy 'ezek a franya userek'. Amikor a domain-je tiltolistara kerul, beregisztral ujat, es megy tovabb. Valahol biztos rosszul latom, mert ez igy tul egyszeru lenne, de hol?

Az SPF alapján a domain tulajdonosa kinyilvánítja egy DNS rekordban, hogy szerinte az adott mail címre mely IP címekről lehet mail-t küldeni. Az ISP-k valszeg csak a saját mail szerverüket fogják megadni, így a DHCP-s usereik csak a szolgáltató mail szerverén tudnak majd levelet küldeni (akarmi@szolgaltato.hu feladóval), ha máshonnan küldik, akkor az default spam-nak lesz minősítve (a fogadó által)

Nézd: mediadreamland.com

volt egy levél a postfix-users listán:

http://archives.neohapsis.com/archives/postfix/2004-06/1652.html

Heteken keresztül jöttek a levelek hogy mennyi spam jön onnan van aki az egyész domain kititotta.

A domain még mindig létezik.

>akkor egyertelmuen azonosithato, hogy en en vagyok.

A domain azonosítható igen. (de az hogy a gépen ki küldte már nem)

>akkor teged bizony sittre vagnak

Szép lenne de sajnos a valóságban nem ez történik.

Nem használnék annyi RBL-t mert nem lenne rá szükség hiszen akik saját hálózatukból spammelnek azokat leállítanák.

Ez már egy üzlet mindenki keres a bulin (csak mi nem).

nem érdekük lecsukni öket....

>ha te nem hasznalod, akkor a leveleid SPAM-kent mennek a /dev/null-ba

Persze így is be lehet állítani, viszont az RFC (tervezet) szerint ilyet nem szabad csinálni.

A másik az hogy ahhoz hogy ilyet lehessen csinálni egyszerre kell az egész világnak áttérni erre a technológiára. (legalábbis a többségnek)

És még mindig nem beszéltünk az open relayekről és proxy-król... ezek ellen se véd a semmit.

Egyedül az ellen véd ha fake címet írsz a feladóhoz.

Még egyszer: a sima SPF-nél nem tudsz levelet továbbítani egy másik email címedre.

Szerinted nem így van?

>axelero spamhost....

Nem mondod hogy innen levelezel?

Valószínűleg a postfix-be lehet a legkönnyebb beépíteni a támogatást. (úgy mint az SPF-t anno)

A postfixben a policy daemon minden adatot átad ennek a daemon-nak (ami lehet egy perl script) majd ő válaszként azt mondja hogy REJECT vagy DUNNO

És a openbsd-ből (sajátkezűleg ;-) linuxra portolt relaydb nevű programot használom arra hogy azokat a hostokat akik szemétkednek velem (system-wide) kitiltsam.

3x ha valahonnan 3x annyi spam jön mint rendes levél, akkor azt mondom neki hogy szia.

Az a jó ha úgy kezdi hogy küld egy spamet minden előzmény nélkül -> feketelista.

aztán aki 30 - 60 napja nem gonoszkodott (talán nem is tudott a tiltás miatt) az lekerül a listáról de egy következő levél által kapásból visszakerül :-))

Vagy olyan gép ahogy 700 bejegyzés van de van ahol 6000 is volt már.

Volt egy-két hely amit kézzel fehérlistára kellett rakni mert nem csinált spamszűrést de valami fontos domain levelezését továbbította ide....

PS: rajta vagyok a openbsd-misc listán olvastam Teo levelét, azért vannak sz@rban mert eddig is csak a sendmail volt megfelelő nekik. (Pedig IMHO a sendmail egy bullshit) A postfix license -sze pedig nem....

Tök mindegy jövő héten csinálok egy OpenBSD tűzfalat úgy is első dolgom az lesz hogy postfix-et rakok rá. :-P

Szerintem egy kicsiket felre van csuszva ez az egesz.

Nezzuk, mit is szeretnenk elerni:

1.; Ne lehessen illetektelen levelet kuldeni

2.; A spam levelek feladoit a torvenyi felelossegrevonashoz szukseges biztonsaggal azonositani lehessen.

Nos, az 1. meg nem eleg, a 2. (a felado megbizhatoan azonosithato) pedig magaban foglalja az 1.-t.

A torvenyi szintu megbizhatosaghoz viszont a kerdest ki kell venni a userek kezebol (ld. self-signed cert nem eleg), ehhez viszont allami, vagy hivatalosan megbizott intezmeny kellene, akik azonositokat/kulcsokat/cert-eket kiadjak/kezelik, meghozza vagy 'alanyi jogon', vagy megfizetheto aron, pl. egy allami CA, ahova bemegyek a szemelyimmel meg floppy-n egy publikus kulccsal, es ok azt alairjak jol. A CA kulcsa meg mehetne a tobbi melle a ca-certs package-be.

Ha lenne ilyen, akkor meg lehetne tenni, hogy az alairatlan leveleket eldobjuk a feszkes /dev/null-ba, tehat a modszer elegseges.

Barmi egyeb esetben egy esetleges per soran jon a kerdes, hogy kinek hisz a birosag, ki tudja illetektelenul generalni az azonositvanyokat -> egy, a birosag szamara 'abszolut megbizhato' intezmenyre van szukseg (mint pl. a szemelyi igazolvany), maskepp nem megy. Ergo a dolog szukseges is.

Lattok hibat a gondolatmenetben?

És mi van ha a hup.hu-ról kapott levelet .forward-dal továbbküldöm? akkor azt mondja a forwardoló gépnek hogy "nem, te nem vagy a hup.hu"?

ja és persze a bounce-ok sem működnek (az SPF-ben).

erre valo a srs: http://spf.pobox.com/srs.html

ez pedig az spf: http://spf.pobox.com/

az srs megjegyzi hogy honnan jött a levél

és ezzel az adattal bővto a FROM mezőt -> meg tudod mondani hogy miken jött keresztül a levél

ha az ISP szolgaltatasi szerzodese nem tiltja explicite a spam-ot (mi is a spam pontos definicoja? reklamlevel? vagy ennel azert szukebb?), akkor vesz a gonosz spammer egy rakat elofizetest, es spamol kedvere, az ISP meg tartja a hatat.

Az ellen nem ved.;-)

Kerem kapcsolja ki!

Nem hiszem, hogy valaki (akar a Microsoft is) azt allitotta, hogy ez megoldja az egesz SPAM problemat. Ez csak a cimhamisitasokat oldja meg.

Nem tudom megitelni a Sender ID hasznossagat addig, amig nem hasznaltam. A Sendmail Inc. azt nyilatkozta, hogy szerinte az elkepzeles nem rossz, en nekik elhiszem, mert biztos jobban ertenek az SMTP-hez, mint en :-)

Engem jelenleg nem is az izgat, hogy technikailag mennyire jo, hanem az, hogy mi lesz a licencelessel. Majd ha a felek megegyeznek a licencelesen, akkor lehet a technikai kerdesekkel foglalkozni.

>Heteken keresztül jöttek a levelek hogy mennyi spam jön onnan van aki az egyész domain kititotta.

A domain még mindig létezik.

Ilyenkor egy telefon az FBI-nak, es ha a spammer szolgaltatoja nem fuggeszti fel a spammer szolgaltatasat, akkor bevonjak az engedelyet.

>akkor egyertelmuen azonosithato, hogy en en vagyok.

A domain azonosítható igen. (de az hogy a gépen ki küldte már nem)

Ha a domain azonosithato, akkor annak szolgaltatoja is. Az ellen el lehet jarni, ha nem fuggeszti fel az abuse ugyfelenek a szolgaltatasat.

Persze nem ved ez attol, hogy valaki olyan orszagban csinaljon spammer gepet, aki magasan tesz a nemzetkozi normakra. De szerintem egy kemenyebb szabalyozassal barkit ki lehetne zarni az internetes szolgaltatasbol. Ez lenne az igazi megoldas. Persze ez ellen ervelni szoktak, hogy az internet szabad, es ez korlatozza a hasznaloit. Szerintem viszont kulonbseget kellene tenni a szabadsag, es a szemetdomb kozott. Olyan szervezet lenne talan a legjobb, aki ugy szabalyozna az internetet, hogy indokolt esetben akar egy egesz orszagot kizar az internetbol. Persze ennek nem tudom mi lenne a kovetkezmenye, es hogy ezt hogyan lehetne megoldani... Elobb-utobb kell valami szabalyozas, mert csak ido kerdese, hogy mikor jelenik meg az internetes terrorizmus.

>PS: rajta vagyok a openbsd-misc listán olvastam Teo levelét, azért vannak sz@rban mert eddig is csak a sendmail volt megfelelő nekik. (Pedig IMHO a sendmail egy bullshit) A postfix license -sze pedig nem....

Na, ezert ez a cime a cikknek:

``Mi az a Sender ID, és mi a probléma vele?''

:-D

Most sem kuldom el a szemelyi igazolvanyom masoltat ha postan adok fel levelet.

Sajnos az, hogy a spammert vissza lehessen keresni, az maga utan vonja, hogy teged is, de ha epp nem spammer vagy, akkor ez inkabb moralis szinten zavaro, nem technikailag. A moralis szintet meg usd ki azzal, hogy nem csak alairod a leveleidet a kulcsoddal, hanem titkositod is, a pgp-intro manpage-en eleg szepen fejtegetve van ez, es legalabbis nekem tetszik, ami ott irva van.


A whitelist maganembernek jo megoldas, de pl. egy ceg nem tudja hasznalni, mert nem tudja, hogy kitol fog uzleti levelet kapni.

Egy ismerosom hasonlo helyzetre mondott egy masik elegans megoldast:

Mikor jon egy level, a 'DATA'-ig megjegyzunk mindent, aztan visszadobunk neki egy 4xx-et. Ha ot percen belul visszajon ugyanazon (ip, felado, cimzettek) kombinacioval, akkor valoszinuleg nem spammer, mert azok nem foglalkoznak hibakezelessel :). Uzleti alkalmazasra persze ez sem mukodik, sot ISP-knel sem, mert az otthoni user MUA-ja nem biztos, hogy ujra fog probalkozni.

Csak két probléma magával a szabvánnyal:

1. Ha valaki A hostról felad egy levelet B hostra, A host ellenőrzi a DNS-t levélfogadásnál, B pedig nincs bejegyezve, akkor soha nem fogja megkapni a B-ről visszapattanó leveleit.

2. Tegyük fel hogy egy host szeretne mindenkivel levelezni, ezért elkészíti a saját DNS bejegyzését, viszont az MTA-ja nem ellenőrzi a DNS-t levélfogadáskor. A spammernek elég erre a hostra, nem létező felhasználóknak küldeni leveleket, amiket az szépen becsomagol, és postmaster feladóval, saját címről juttatja el a célfelhasználónak, és bizony az ottani MTA már mindent rendben fog találni a DNS-ben, és boldogan kézbesíti a bounce-olt spam-et.

Lehet, hogy félreértem, de szerintem nem oldja meg a címhamisítást. Ha te ugyanarról a szerverről, vagy IP címről (amit te is szabadon megnézhetsz a DNS-ből) tudsz levelet küldeni, már küldheted is a hamisított leveleket.

Erre rengeteg mód lehet. DNS hamisítás, IP cím hamisítás, gépfeltörés, hogy a nehezebbeket mondjam, de akár lehet egy ilyen pre-paid internet előfizetés, open relay a szolgáltató tartományában vagy bármi.

Szerintem elég hosszú a lista, csak az én fantáziám korlátos.

Ide válaszolj :) [portal.fsn.hu]

>>És mi van ha valaki a ez-egy-spammre-letrehozott-domain-egy-heting-spammelek-innen.com -ról küld levelet?? semmi ugyanúgy megérkezik a levél.

>Nem erted. Ha mindenki hasznalja a Sender ID-t (nem en mondom, hanem ez az elkepzeles, de az is lehet, hogy en ertem felre), akkor egyertelmuen azonosithato, hogy en en vagyok. Ha te letrehozol egy spam domain-t, akkor teged bizony sittre vagnak. Hogy miert? Mert te jegyezted be a domaint. Megkeresheto vagy.

Lehet, hogy en ertem felre, de ha jol latom, akkor itt IP-k es domain-ek osszekotese az egyetlen, amit csinalunk.

Tehat ha en mondjuk talalok egy olyan ceget, aki dinamikus IP-vel kapcsolodik egy szolgaltatohoz, pl. ADSL-lel, vagy dialup, akkor attol a szolgaltatotol az o nevukben vidaman kuldhetek spam-et.

Jo, latom en, hogy sok minden kiszurheto, pl. akarmi.hu cimu levelek nem erkezhetnek tavolkeleti gepekrol.

De valahogy szkeptikus vagyok. Szerintem IP alapjan eddig is vissza lehetett kovetni a spammert valameddig.

Pont ezert worm-mal felnyomott gepeket, meg open relay-t hasznalnak.

Ezentul csak arra kell figyelni, hogy a from header, vagy a hamisitott received sorok, vagy akarmi, amit figyel a protokol, azok szepen egybevagjanak a felnyomott geppel.

Szerintem ugyesen automatizalhato a dolog.

En ugy gondolom, hogy csak a kulcsparos digitalis alairas erhet valamit.

Legyen minden MTA-nak egy GPG kulcsa, es irja bele a levelbe, hogy errol az IP-rol kaptam, erre kuldom tovabb, ennyi orakor. Alairas.

Igy pl. ha az ismeroseimtol jon a level, akkor rogton alairasellenorzes utan a teljes spam kergetest ki lehet hagyni.

Ha meg mashonnan jon a level, akkor szepen vegig lehet nezni a received sorokat, hogy van-e valahol hazugsag, hiszen a spammer nem tudja mail.masceg.com MTA-janak az alairasat produkalni.

Ha meg alairatlan level jon, akkor szepen erosen megnezem.

Biztos ezt az otletet is lehet meg tokeletesiteni, de valahogy ugy erzem, hogy hitelesites nelkul az egesz kijatszhato.

Ezt úgy hívják hogy greylisting. Én több helyen is használom.

>Uzleti alkalmazasra persze ez sem mukodik, sot ISP-knel sem, mert az otthoni user MUA-ja nem biztos, hogy ujra fog probalkozni.

Dehogynem! Az otthoni user MUA-ja a ISP smarthostjához kell hogy küldje a levelet, az pedig majd újrapróbálgatja..

Tudsz user@szolgaltato.hu feladójú e-mail-t küldeni bárhonnan, ha a szolgáltató engedélyezi - autentikáció után - hogy bárhonnan használd az smtp szerverét. Az smtp szerver beállításakor meg kell adni a bejelentkezési adatokat, és akkor bárhonnan használhatod...

és akkor még nem beszéltünk arról, hogy bárki aki saját maga kezeli a DNSét olyan bejegyzést ír bele amilyent csak akar és ezzel ki van lőve a senderid a francba