Ny anti-spam teknik

Ja, for MS har stirret sig blind på Sender ID

Godt tiltag - men jeg synes ikke artiklen beskriver metoden ret godt. De bliver bare ved med at sige det er en mere eller mindre "intelligent" algoritme, og at den - i sammenhæng med text-analyse tests - vil hjælpe mod spam.. Men jeg kan ikke umiddelbart forstå hvordan den gør det.. Hvis den bare tjekker, at alle de mail-servere den pågældende e-mail er gået igennem, er "populære" og "kendte" servere, så vil folk med egen private mail-server få problemer..
Jeg mener, jeg kunne jo sagtens begynde at udsende bunker af spam-mails fra min egen private server og, bortset fra text-analyse filteret, ville det nye filter jo ikke kunne kende forskel på disse spam-mails og normale "lovlige" mails. Ville det?
Nogen der har yderlige information ang. dette problem?

Problemet er at det ikke er særlig mange mailservere der skriver på hvilke steder den har været igennem. Desuden er udgående port 22 lukket på alle ISP'er, så man skal bruge isp'ens mailserver. Jeg har endnu ikke set nogen af disse skrive afsender IP på.
så WTF går denne artikel ud på?

ahva? - port 22 er ssh, hvad har det med noget at gøre?
ligeledes har jeg aldrig hørt om en isp der blokerer port 25 udafgående? Dog er det normal med indgående forbindelser på port 25 blokeres, men er absolut ikke alle.

#3 - med TDC kan du faktisk bruge din egen mailserver, ved at bruge deres mail-backup server og ændre i dine MX records for domænet. På følgende måde f.eks. :
Vært: mail udveksler: Præference: TTL
w00p.dk mail.w00p.dk 10 43200
w00p.dk backup-mx.post.tele.dk 20 43200
(undskyld, det blev formateret lidt morsomt..)


Og så kan man jo selv bestemme om man vil lade serveren skrive til headeren..

Det er tankevækkende at en forsker fra Microsoft udtaler sig positivt om brug af kryptografisk autentificering, når de samtidigt selv arbejder for indførelse af SPF. Det ville nok gavne kampen mod spam hvis Microsoft i stedet for arbejdede for indførelse af domainkeys, som netop gør brug af kryptografisk autentificering af mailen. Samtidigt har domainkeys ikke det problem med forwarding som kendetegner SPF. Det virker som om Microsofts kamp for andele på markedet for mailservere har højere prioritet end kampen mod spam.

[url=#4]#4[/url] Mazon

ligeledes har jeg aldrig hørt om en isp der blokerer port 25 udafgående?

Det gør Webspeed som default.

[url=#5]#5[/url] jlor

med TDC kan du faktisk bruge din egen mailserver

Selv det blokerer Webspeed for som default.

Det skal siges, at på Webspeed kan det lade sig gøre at få åbnet for port 25. Det er bare en stor udfordring, da dem de har ansat til at tage sig af det faktisk aldrig har hørt om SMTP. Første gang jeg kontaktede dem fik jeg at vide, at det kunne bestemt ikke lade sig gøre. Da jeg senere hørte at andre havde haft held til det besluttede jeg mig for at prøve igen. Efter at være blevet stillet frem og tilbage mellem de samme to afdelinger en håndfuld gange lykkedes det til sidst at få åbnet.

#2 en måde den kunne gåre det på var f.eks. at tjække om ip'erne stammede fra samme netværk som indkommende mail server, kigge på sprog vs ophavsland, eller om ip'en er fra et netværk der ofte sender spam.
Altså ved at sammenligne headere på åbentlyst spam mails og mails i grense området vil man kunne afgøre flere tvivlspørgsmål bedre, end hvis man kun kiggede på inholdet.
Om det rammer de små tjaa hvis IP'en for afsender er identisk med MX record tjaa så er der ikke tale om skumle spam teknikker med zombie'r og tilsvarende.

#6 SPF er væsentligt mildere overfor hjemme servere end domainkay og tilsvarende, det godt nok er effektive men vil bevirke langt mere centraliseret kontrol af SMTP systemet

Lige en quickie : Gør Firetrust (Mailwasher) ikke allerede det som nyheden omhandler med deres indbyggede (i Mailwasher) FirstAlert og Origin of Spam ?

Ikke et punk mod nyheden, men et reelt spørgsmål. :-)

edit:

- Origin of Spam : "MailWasher allows you to check the origin of the email received against DNS spam blacklist servers."

- FirstAlert : "When you check your email with MailWasher, FirstAlert! trains the filters in MailWasher against the latest spam threats so you're always up-to-date."

#4, #5
Uuups, ja port 25.
Jeg kan ikke forstå I ikke har hørt om blokeringer af udgående port 25.
Tele2, lukket:
http://resources.tele2.dk/privat/help_popup/popup_...
Tdc, lukket:
http://sikkerhed.tdconline.dk/artikel.php?id=58048
Cybercity: Har åbent :)
Telia, lukket:
http://www.stofa.dk/showpage.php?conid=95&menu...

MX tricket er kun til _indgående_ post, det har ikke noget med den her teknik at gøre.

Dem som spammer skulle skydes, så dum har man sku ikk lov til at være

kasperd: det lyder PRÆCIS som min oplevelse sidste efterår
http://www.newz.dk/forum/item/50496/

men ellers er jeg godt tilfreds med webspeed, det her er det eneste problem der har været

#9 tjo der er vist noget om det, men man kan sætte sin mailserver til at sende udgående post igennem smtp.mail.dk f.eks.

#8> Ikke helt, problemet med "Origin of Spam" - også kendt som "Reverse DNS blacklisting" - er at den kun fanger spam fra afsendere hvis IP adresse er på en af listerne over kendte åbne/usikre SMTP servere.
FirstAlert lyder som en checksum kontrol op mod en central server (i stil med det danske tiltag SpamFighter).

Det står godt nok ikke ret meget om hvordan det virker, men mon ikke snart det kommer.
Jeg vil gætte på den kigger stien igennem, og blandt andet hæfter sig ved om en e-mail sendes igennem relay eller ej, og om de relay der benyttes er en del af afsenderens netværk, ellers er det jo ikke normalt noget der benyttes.
Mon ikke også den f.eks. lægger mærke til når man modtager en e-mail fra en afsender der udgiver sig for at hedde f.eks. et IP nummer (ser en del e-mails efterhånden der udgiver sig for at hedde det IP nummer som mine MX records peger på).

Når det nu er IBM, og det er anti-spam, håber jeg da algoritmen bliver offentlig... snart..!! Reverse DNS tager en del, og SPF tager også nogle stykker (bare ikke nok der bruger det), såeh..

#10> Dem som reagere på spam skulle skydes! Op mod 11% reagere, derfor kan det betale sig, desværre!

#12 well det er bare at følge linksne fra siden.
http://www.ceas.cc/papers-2005/176.pdf
Udover at den ikke tjækker på sprog er det groft sagt som jeg beskrev i #7

[url=#7]#7[/url] DUdsen

SPF er væsentligt mildere overfor hjemme servere end domainkay og tilsvarende, det godt nok er effektive men vil bevirke langt mere centraliseret kontrol af SMTP systemet

Det er ellers noget af en påstand. Det fik mig så til at undersøge, hvordan det rent faktisk virker, og jeg fandt ud af, at du tager fejl. Begge metoder virker ved at tilføje en TXT record til DNS domænet. De er altså nøjagtigt lige centraliseret.

Der er en lille detalje ved DomainKey, som jeg ikke ved hvordan virker. Hvordan finder man ud af, om et domæne har en DomainKey? Hvis mailen har en DomainKey header er det nemt nok, man bruger bare selectoren fra headeren for at slå den offentlige nøgle op. F.eks.

dig -t txt beta._domainkey.gmail.com

Men hvis nu jeg modtog en mail med gmail.com som afsenderdomæne og ingen DomainKey header, hvordan kan jeg så vide, at selectoren hedder beta?

#14 Problemet med domainKay er at det storset er samme system som SPF bare pakket ind i asynkron kryptering.
Det løser en masse problemer med SPF men dybest set er den eneste forskel at DomainKey ud over en txt record krever signering af mails
hvad er forskellen på at tilføje en txt record og en hjemmegeneret uverificeret krypterings nøgle?, det kan hurtigt komme til det punkt hvor du skal til at betale verisign for en nøgle til din email server!

Er de bare mig eller er vinklen forkert? Jeg har interesse i at et spamfilter ALDRIG fanger en legitim mail, hvis der kommer en smule smuds ind overlever jeg.

Reklamerne lyder altid "VI fanger MERE!".

[url=#15]#15[/url] DUdsen

Problemet med domainKay er at det storset er samme system som SPF bare pakket ind i asynkron kryptering.

Det er overhovedet ikke det samme, det er to vidt forskellige måde at afgøre en mails legitimitet. SPF checker klientens IP adresse, hvilket umuliggør forwarding. DomainKeys kigger overhovedet ikke på IP adressen.

Der er ingen kryptering indblandet i DomainKeys, kun signaturer. (Hvad er asynkron kryptering for noget, det har jeg aldrig hørt om i de fire år jeg har studeret indenfor området. Mener du ikke asymmetrisk? (Og hvorfor skal Kay nu blandes ind i det?))

hvad er forskellen på at tilføje en txt record og en hjemmegeneret uverificeret krypterings nøgle?

Forskellen er, at hvem som helst kan generere nøglen. Men kun administratoren af domænet kan tilføje den til zonefilen. DomainKeys skal på ingen måde ses som erstatning for konventionelle signaturer, det skal blot ses som et våben imod spam, som gør det væsentligt sværere at spoofe en afsenderadresse.

det kan hurtigt komme til det punkt hvor du skal til at betale verisign for en nøgle til din email server!

Man skal ikke betale for at bruge SSH. Man skal ikke betale for at bruge GPG. Man skal ikke betale for at bruge DomainKeys. Men hvis det står til Microsoft kommer man nok til at betale for at bruge SPF.

[url=#16]#16[/url] bugger

Jeg har interesse i at et spamfilter ALDRIG fanger en legitim mail, hvis der kommer en smule smuds ind overlever jeg.

Selvfølgelig er vi ikke interesseret i, at et spamfilter fanger legitime mails. Men den eneste måde man kan give den garanti er ved at afskaffe spam og fjerne filtrene.

Som det ser ud i dag er det at fjerne filtrerne ikke rigtig realistisk for mange personer. Man modtager hurtigt adskillige spam mails hver time. Prøv at komme hjem fra ferie og skulle sortere 1000 mails. Så vil du sikkert heller ikke selv kunne gøre det fejlfrit. Det er altså ikke urealistisk, at filtrene kan give lige så lav fejlrate som manuel sortering.

#17 Precist den eneste forskel at at hvor SPF Bare kigger på IP'er har DomainKey potientielt det problem at det kommer til at læne sig op af både DNS records og en PKI-infrastruktur, og ikke som SPF kun af DNS records.

Og hvorfor tror du ikke at MS med de rette patenter kan komme til at kontrolere DomainKey eller hvis ikke MS gør så et eller andet andet skummelt firma som f.eks. Eolas.
MS har garenteret at SPF ikke er afhængigt af patentlicenser fra MS, senderID er en lidt anden sag, men det rå SPF er ikke under MS kontrol og så vidt jeg ved har IETF accepteret SPF, som en standard.
Du ser dig blind på MS's påståede ondskab, de har bla på grund af hotmail rimeligt brug for et effektivt system der rent faktsik bliver implementeret og her er SPF tættere på end DomainKay.
Lad os kigge på gmail.com altså dig -t txt gmail.com bemærk ingen domainKay men en SPF entry.

Kigger du på hvordan tingene fungere i praksis så kan du sagtens generere en nøgle men ingen tager dig rigtigt seriøst hvis du ikke har en nøgle der er udstedt af en anerkendt organisation, som verisign, og du kommer formenteligt ikke til at kunne bruge dine GPG nøgler i DomainKey-systemet.
Det er rigtigt nok at DomainKey løser problemet med forwards osv men prisen er kompleksitet.

#16 en af fordelene ved SPF og domainKey er at det kan bruges som whitelist, og den foreslåede algoritme ser ud til også at reducere antallet af falske positive.
Intet er 100% precist men jo flere paremetre man kigger på jo mere precist bliver filtrene.
Jeg er lidt enig med dig i at falske positiver er det største problem ved de filtre man bruger idag, ikke de små mængder spam de ikke fanger.