Názory k článku
DKIM – dopisy ověřeného původu

Jestli jsem to dobre pochopil tak oproti SPF to jen navic, diky podepisovani, zarucuje integritu prenaseneho emailu. Skoda, ze uz z principu je problemem pro vsechny tyhle systemy i obycejne preposilani.

myslim, ze to nabizi mnohem vic.

v SPF existuje zaznam jen pro zdrojovy server, kdezto v pripade DKIM muze pridat svuj podpis kazdy server, skrz ktery to projde.

jinak obycejne preposilani Vas nepripravi o nic, protoze je to de facto zcela nova zprava.

dulezite je, ze je konecne explicitne receno, ze toto reseni slouzi jako whitelist. u SPF to receno nebylo, takze to nekteri admini (skoro bych rekl, ze vetsina) chapala jako blacklist, tj. ve vyznamu "nemas patricny zaznam? no tak jsi spammer". a pokud to doplnili o zadrzeni takoveho "spamu", bylo o zabavu postarano. no... ale o tom uz toho bylo napsano dost.

ne nemáš záznam - jsi spammer, ale - SPF záznam říká něco jiného (tvoje IP tam není) - jsi (asi) spammer

z openspf.org:

Does SPF break forwarding?

Yes, but only if the receiver checks SPF without understanding their mail receiving architecture. If receivers are going to check SPF, they should whitelist forwarders that do not rewrite the sender address from SPF checks.

problem je totiz v tom, ze kdyz mate forwardujici server, tak ho musite na strane prijemce whitelistovat, jinak ho budete podle Vaseho pristupu pokladat za spammera. jenze whitelistovat forwardery neni az takova legrace. a navic skutecny spammer odesilajici z whitelistovaneho serveru... to je sen kazdeho admina - mineno ironicky.
(ten citat nahore jsem uvedl, abych zkratil diskusi zde. oni jsou si asi sami dobre vedomi slabin sveho reseni. ;-))

Jak dlouho ještě bude firma Seznam porušovat RFC (číslo už si nepamatuji) ohledně data emailu (at Thu Nov 22 14:24:21 2007)?!

Received: (qmail 29967 invoked by uid 0); 22 Nov 2007 13:24:25 -0000
X-Spam-Checker-Version: szn-spamassassin 2006-02-02
X-Spam-Status: score=8.4
Received: from 213.93.76.103
	by email-mx3.go.seznam.cz Seznam SMTPD 1.0.15@12237:12245;
	at Thu Nov 22 14:24:21 2007 
Received: from [213.93.76.103] by mail.02.net; Thu, 22 Nov 2007 14:36:57 +0100
Date: Thu, 22 Nov 2007 14:36:57 +0100 (CET)

RFC 2822

SMTP je z let osmedesatych, nikoliv sedesatych :-)

Onen problem lpeni spociva v kouzelnem spojeni, ktere se zove "zpetna kompatibilita".

Mimochodem, spammeri nepouzivaji domeny, ale konkretni pocitace.

>spammeri nepouzivaji domeny, ale konkretni pocitace.
To ale neznamená, že si nemohou na chvíli zřídit doménu zapsat DNS záznamy a poslat pár milionů mailů z nějaké svojí farmy zombíků....

Aha, v tom pripade ano. Nicmene tim DNS zaznamem (AFAIK) demaskujou tu svoji farmu (celou a na jednom miste).

Vy jste teda expert! Tak za prve - netusim, proc by protokol A mel byt povinne kompatibilni s protokolem B... (Gopher vs. HTTP), zatimco tady se stale mluvi o jedinem protokolu a sice SMTP - napada me neco o jabkach a hruskach...

Za druhe - nevim, kde jste vycetl, ze velikost zpravy muze byt max. 512kB. Mozna je na case vystrcit hlavu z pisku a pripadne obmenit provozovane technologie ci neschopneho dodavele. Znam "taky uzivatele", kterym nedela problem posilat stovky MB velike vykresy a jine informace. Za akceptovatelnou velikost dnes povazuji par desitek MB... - doba, kdy bylo vhodne rozdelovat e-mail zpravy na bloky o velikost cca 64kB je davno za nami a prameni z nemoznosti navazat na rozpadlou komunikace = musela se cela zprava poslat znovu, coz byl na komunivanych (a desne spolehlivych) linkach (o kapacitach maximalne bar desitek tisic baudu) v te dobe problem, dnes je to spise o kapacite a propustnosti koncovych SMTP serveru nez o problemu fyzicke prenosove trasy.

Obavam se, ze si nerozumime. HTTP a Gopher jsou dve aplikace a dva ruzne svety. V pripade, ze byste chtel zavest nejak CMTP (Complex Mail Transfer Protocol), musel byste zajistit nejake brany ze stareho do noveho systemu a musel byste presvedcit uzivatele (tj. administratory), aby odmigrovali do noveho.

V pripade, ze byste mel nejake brany, pak by se tyto chovaly bud transparentne (a propoustely treba spam) nebo by zasahovaly do obsahu (a nejaky e-maily nepropoustely), coz je prusvih.

Co se tyce moznosti stahovani dat z odesilajiciho serveru, tak se obavam, ze jde zcela mimo filozofii e-mailu. E-mail je davkova sluzba a jako takova nemuze spolehat na nejake on-line zdroje. I dnes jsou zeme, kde je vytacene pripojeni velkym vydobytkem. A uzivatele z technto zemi pouzivaji stejnou sadu protokolu jako uzivatele treba Nizozemi nebo Jizni Koreje.

Co se velikosti tyce, je to otazka na konkretniho administratora konkretniho systemu. Napriklad technicky model onech gigabajtovych schranek freemailu je zalozen na tom, ze vetsina uzivatelu nebude dostavat zadne velke e-maily a tim schranku nenaplni.

Protoze uz v oblasti jednotek TB se dostavate do problemu s cenou diskovych subsystemu a kdyz budete mit byt jen desetitisice uzivatelu a kazdy bude mit gigabajt e-mailu, tak to bude pomerne draha legrace.

Mimochodem, obcanske sdruzeni, ktere financuji, ma velikost e-mailu omezenou na 10 MB a velikost INBOXu na 50 MB.

Mám pocit, že jsem tuto technologii až tak docela nepochopil. Má to nějaký jiný přínos než ten, že se adresát dozví, "ano, tato zpráva opravdu prošla přes náš server", tj. že to může sloužit jako ochrana před phishingem? Specielně mi opravdu není jasné, jak by tohle mohlo pomoci v boji proti spamu - leda snad v tom, že už dnes přetížené mailservery zkolabují úplně, protože prostě nebudou stíhat podepisovat ta kvanta přeposílaných spamů, čímž se rozeslání spamů (a taky normálních mailů) zastaví...

Tohle je vec, kterou navrhuji uz spoustu let a oni to mezitim stihli implementovat.

Proste vsechny podepsane emaily jsou na 99% ne-spam (muze jit o spam, nicmene pak ale vis kdo ti ho poslal), takze tyto emaily nemusis vubec kontrolovat - zadny false-positive.

Neverim, ze byste byl mimo zorny pohled spameru, kteri neadoptovali k obrazu svemu DomainKeys, SPF a dalsi neuspesne pokusy zamezit sireni spamu (BTW kdepak mame MS reseni, jak nam strycek Bill do dvou let sliboval?! Ze by u nich platil jiny planetarni cas?)

Tohle?
http://www.lupa.cz/clanky/apache-a-debian-lek-na-spam-od-microsoftu-sirit-nebudeme/
Všimněte si data článku, stačí letopočet.