Názory k článku DKIM – dopisy ověřeného původu
-
Peppa1 (neregistrovaný)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)
-
N/A (neregistrovaný)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. -
pepak (neregistrovaný)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í...
-
Anička (neregistrovaný)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. -
N/A (neregistrovaný)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. ;-)) -
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. -
anonymníVzdycky mne udivuje, jak dokaze IT prumysl na jedne strane silene rychle vyvijet a aplikovat nove technologie a jak na druhe strane lpi na zastaralych a polofunkcnich technologiich ze sedesatych let.
Namisto toho, aby se konecne vyvinul nastupce mailu, ktery by jeho notoricke nedostatky vyresil od zakladu, tak se porad jen a jen flikuje...
Tato technologie vypada sice hezky a ma i zatim solidni podporu, ale jak jsem z clanku pochopil, nevyresi temer nic. Kdo potrebuje autentizovanou komunikaci s obchodnimi partnery, davno uz pouziva sifrovani a podpis klient-klient. Spolehat se v tomto na server je imho bezpecnostni dira. DKIM mi v nejlepsim pripade rekne, ze mail z blablabla.cz byl skutecne odeslan pres postovni server na blablabla.cz. Co bude branit spamerum, aby meli take autentizovany mailserver? Jedina cesta je pak blacklisting znamych spamerskych domen, coz je ale pri dnesnich cenach domen pro spamery problem naprosto minimalni. -
anonymníA treba HTTP je zpetne komaptibilni s Gopherem jak?
Maily maji tisic problemu, z cehoz DKIM resi jenom podvrzeni adresy odesilatele. Co treba notoricky problem s odesilanim vetsiho mnozstvi dat pomoci mailu? Je normalni, ze se v roce 2007 bezne pouziva omezeni na max. velikost zpravy 512kB??? Mne to tedy normalni neprijde. Tohle by pritom vyresila zcela primitivni moznost stahnout data primo z odesilajiciho serveru. -
PaJaSoft (neregistrovaný)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.
ČLÁNKY DO MAILU