Vlákno názorů k článku Nenechte se odposlouchávat, používejte a vyžadujte šifrované SMTP od Dan Ohnesorg - Ac s clankem 100% souhlasim, musim varovat pred...
-
Ac s clankem 100% souhlasim, musim varovat pred tim, abyste hned zitra zacali na SMTP zapinat sifrovani. Pokud totiz budete anoncovat STARTTLS a pritom nebudete mit duveryhodny certifikat, prestane vam prichazet posta. Parkrat jsem si s tim hral a vetsina tech co SSL pouziva to ma implementovane spravne a uzavre spojeni, jakmile predlozite neplatny certifikat.
Nasadit duveryhodny certifkat zni strasne snadno, dokud se nepodivate do DNS a nezjistite, pro kolik ruznych jmen ho budete potrebovat, potazmo v kolika ruznych domenach musite predelat MX zaznamy, abyste vsude pouzili to jedno jmeno, pro ktere mate SSL certifikat.
-
Jenda (neregistrovaný)
„Parkrat jsem si s tim hral a vetsina tech co SSL pouziva to ma implementovane spravne a uzavre spojeni, jakmile predlozite neplatny certifikat.“
Což je možná formálně správně, ale přijde mi to nelogické - tedy alespoň dokud nemá protistrana šifrování nastavené jako povinné. Takhle se totiž dostáváme do situace:
- neumím STARTTLS, pošta mi normálně chodí nešifrovaná
- naučil jsem se STARTTLS, ale prokážu se certifikátem, kterému protistrana nevěří - a protistrana odmítne doručovat. Proč? Vždyť by doručila i plaintext. Nedůvěryhodný certifikát přece není o nic méně bezpečný než plaintext, se kterým nemá problém (naopak je bezpečnější, je potřeba MITM, nestačí pasivní poslech)
-
MilanK (neregistrovaný)
A ještě horší je to s ověřováním odesílající strany: pokud bych chtěl zabránit ověřováním certifikátu útoku MITM, tak musím (kvůli odstranění STARTTLS útočníkem) ověřit i certifikát druhé strany (ne pouze protistraně předkládat ověřený certifikát). Ale vzpomínám si, že jsem musel autorizaci odesílající strany (TLS klienta) přestat požadovat, protože jsou SMTP servery, které sice na TLS při odesílání přejdou, ale odmítnou se identifikovat certifikátem.
-
je to celé pochybné (neregistrovaný)
"lepší nedůvěryhodné TLS spojení než zcela nezabezpečené" - tak s tímhle nesouhlasím. Nedůvěryhodné TLS spojení dává pouze falešný pocit bezpečí, který je mnohem nebezpečnější než poctivě priznané nebezpečné spojení. Když si totiž nebudu nalhávat že spojení je zabezpečené, budu se podle toho chovat - nedůležité maily prostě pošlu, důležité zašifruji (např. pomocí GPG).
Navíc celé SMTP STARTTLS je dost pochybné z principu - když pomocí MITM z ohlašování schopností serveru odeberu STARTTLS, SMTP klient klidně pošle útočníkovi data nešifrovaná (ten je pak dál serveru už může poslat zašifrovaná).
A ještě jeden důvod proč SMTP STARTTLS je pochybné zapezpečení: poskytovatel hostingu SMTP serveru může být kdykoliv donucen vydat privátní klíč (např. dumpem paměti v případě VPS nebo obsahem disku kde klíč taky může být nešifrovaný), takže spoléhat na toto zabezpečení je opět pouze falešný pocit bezpečí. Myslím že Petr Šťastný si tohoto musí být vědom, jsem přesvědčený že kdyby firma ve které pracuje dostala takový soudní příkaz tak data klientů také vydá.
-
SMTP TLS v současné době na veřejném Internetu MITM nezabrání, to je ve článku zdůrazněno. Šlo by to jen kdyby úplně všechny servery používaly a současně vyžadovaly důvěryhodné certifikáty. Ale to aktuálně nejde. Takže pokud to někdo chce myslet s bezpečností svých dat vážně, musí použít end-to-end šifrování.
Také je potřeba rozlišit pohled, ze kterého se na to celé díváme. Třeba administrátor SMTP serveru může právě ovlivnit šifrování SMTP, ale end-to-end šifrování jde mimo něj. Naopak koncový uživatel neovlivní co se děje na cestě mezi odesílatelem a příjemcem (a 99,99% lidí je to úplně jedno a ani neví jak to funguje), ale může šifrovat své zprávy před odesláním.
Podle mého názoru zapnutím TLS na serverech admini rozhodně nic nezkazí. Bude to lepší než předtím. Samozřejmě je vhodné, aby admin dobře celé problematice rozuměl a byl si vědom výhod, nevýhod a možných komplikací (a třeba i toho falešného pocitu bezpečí).
-
j (neregistrovaný)
Nesouhlasis zcela zbytecne ...
1) "duverovat" jakesi "autorite" - tedy zcela cizimu subjektu, se kterym nemam v uzavrenou ani zadnou smlouvu, a ani neznam jeho interni procesy ... je naprosta magorina
2) autorizovat certifikat kazdyho potencielniho komunikacniho parnera je zcela nerealny technicky
3) tudiz TLS neni nastrojem k overeni protistrany, ale nastrojem k zamezeni odposlechu dat cestou - a v takovym pripade je mi zcela uprdele, jaky certifikat protistrana pro sifrovani pouziva.Samo, mohl bych (rekneme) jeste maily rozrtidit dle 3 kriterii
a) ty, ktere prisly od certifikovaneho a autorizovaneho subjektu
b) ty, ktere dorazily sifrovanym kanalem, ale neplati pro ne bod a (pricemz netusim, zda nekde cestou nesly kanalem zcela nesifrovanym)
c) ty, ktere dorazily jako open textA samozrejme, presne totez plati trebas pro https, kde je pro me kdokoli s selfsignet certifikatem naprosto stejne duveryhodny, jako kdokoli s certifikatem od verisignu. V oboou pripadech, pokud uz se rozhodnu certifikatu "duverovat", dam si do stromu duveryhodnych jen a pouze prave ten jedinej certifikat.
-
j (neregistrovaný)
Tak to uz je zcela na me, ovsem. Kdyz se mi nekdo na ulici predstavi "Pepa z depa" ... tak mu taky verit muzu a nemusim. Stejny je to s tema certifikatama. Kdyz si po vyskoceni oblibene hlasky o "neduveryhodnem" certifikatu tento pridam mezi duveryhodne, tak jediny co vim je to, ze priste komunikuju se stejnym subjektem - tedy tim, kdo ma ten klic pod kontrolou. A kdo to realne je, je mi dost casto zcela jedno.
Az budu mit potrebu komunikovat zabezpecene se snowdenem, tak si snim vymenim klice na ryzovem papire, ktery vzajemne po overeni pred sebou zblazjneme (samo, s nalezitou dobou nasledneho dohledu, aby doslo k dokonalemu straveni) ;D.
-
UnTrusted (neregistrovaný)
Říkáš to vše dobře, ale ještě bych chtěl poukázat na jednu natolik samozřejmou věc, že může leckdo na ni zapomenout.
Nestačí přijmout jméno neznámého cizince a použít jeho self-signed certifikát. Ještě je třeba věřit, že zrovna on je jediným držitelem soukromého klíče. Osobně bych řekl, že zde je takový self-signed certifikát důvěryhodnější než složitý řetězec certifikátů končící u neméně pochybné CA.
-
j (neregistrovaný)
Ciste z principu pravdepodobnosti ... defakto neni co resit, selfsigned je radove bezpecnejsi. Uz jen proto, ze utok vedeny na nejakou tzv "duveryhodnou" autoritu je o nekolik radu pravdepodobnejsi.
Mimochodem, ted sem si tak vzpomel, ze kdysi sem nekomu zarizoval nejaky podpis pro bankovnicvi, a co me dostalo do kolen, ze sem se kolem toho asi mesic s bankou dohadoval, protoze oni chteli vse generovat na svy strane ... s tim ze klic nasledne klientovi predaji na diskete (na nicem jinym to neumeli) ... a ja se snima dohodoval kvuli tomu, ze sem jim hodlal dat k dizpozici pouze verejnou cast klice. Nakonec sem se dohadal na nejakyho admina, kterej mi samo odkejval, ze mam pravdu. Ale kterej ustav choromyslnych to byl si bohuzel uz nepamatuju ... ovsem myslim ze kdyz strelim nekam kolem KB/CSOB ze nebudu moc vedle.
-
j (neregistrovaný)
Nemuzu, protoze se tak nechova ... trebas revokovat ho klidne muze ta autorita, a ja ani drzitel stim nic neudelame. Jiste, muzu tuhle ficuru pominout a nepouzivat ji.
Navic uz jen to, ze ten certifikat je nekde evidovanej = potencielni bezpecnostni riziko. Jednoduse se vi komu patri (nebo se to aspon tusi) a to v mnoha pripadech je celkem zasadni problem.
-
Jenda (neregistrovaný)
„a ja ani drzitel stim nic neudelame. Jiste, muzu tuhle ficuru pominout a nepouzivat ji.“
No vždyť o to právě jde - chovej se k němu jako k selfsigned, když ti CA vadí! Selfsigned taky nerevokuješ, tak revokace ignoruj.
„Navic uz jen to, ze ten certifikat je nekde evidovanej = potencielni bezpecnostni riziko. Jednoduse se vi komu patri (nebo se to aspon tusi) a to v mnoha pripadech je celkem zasadni problem.“
To si teda upřímně řečeno nedokážu moc představit (ostatně ten selfsigned je vystaven na veřejném mailovém serveru)…
-
Filip JirsákStříbrný podporovatelKaždá rozumná certifikační autorita má procesy týkající se bezpečnosti zdokumentované a zveřejněné. Když neověříte certifikát protistrany, nemůžete ani zamezit odposlechu – útočník vám prostě pošle svůj certifikát a pak si vesele poslouchá.
-
j (neregistrovaný)
Jakou mam moznost si overit, ze ty procesy dodrzuji? Aha, presne nulovou. Kolik tech "overenych" autorit uz vydalo certifikaty v rozporu s temi procesy? Vim minimalne o desitkach pripadu. A to jsou jen ty, kdy se to proflaklo. Realne jich bude minimalne o rad nebo dva vic.
Jedinej duverychodnej zpusob jak overit certifikat je ho ziskat primo od dotcene osoby. A ani to nezaruci, ze jej nepreda nejake treti osobe.
-
Filip JirsákStříbrný podporovatel
U státem akreditovaných autorit má možnost kontroly určitě stát. Nevím, jak je to u zařazení mezi důvěryhodné autority Firefoxu nebo Microsoftu, zda tam existuje nějaká možnost kontroly. Každopádně to, že nic nevíte o interních procesech CA, je jen váš problém. Pokud jste chtěl napsat, že nemáte možnost ověřit si dodržování stanovených postupů, neměl jste psát, že o interních procesech nic vědět nemůžete.
-
Lol Phirae (neregistrovaný)
U státem akreditovaných autorit má možnost kontroly určitě stát.
No jistě, viz DigiNotar :-))))))
-
j (neregistrovaný)
Statem "akreditovane" autority jsou naopak naprosto neduveryhodne. Na ty uplatnuju vseobecny ban.
Mimochodem, mr Jirsak jiste chodi pravidelne na audit ke kazde "autorite", vcetne tech statnich, takze jiste muze napsat, jak to tam chodi ... Ono totiz sehnat certifikat na "pepu z depa" neni nijak zasadni problem. Staci nejakyho nabrat na ulici a dat mu na pivo.
-
Filip JirsákStříbrný podporovatel
Má ten váš argumentační postup nějaký název? Já bych to nazýval třeba "krok stranou". Vždy něco napíšete, a když vám někdo oponuje, napíšete "to nevadí, ale" a vymyslíte si něco nového. Nevadí vám ten drobný detail, že takhle žádnou svou tezi nikdy neobhájíte?
Nevím, na základě jakých dojmů považujete za nedůvěryhodné všechny státem akreditované autority. Ani nevím, co se změnilo, že jste před pár komentáři o interních procesech autorit nevěděl zhola nic, a teď už víte, že není problém získat certifikát na "pepu z depa". Za to bezpečně vím, že certifikát "pepy z depa" vám pro konfiguraci TLS pomůže jedině tak, že jím podepíšete objednávku, aby vám to nakonfiguroval někdo, kdo tomu aspoň trochu rozumí, a neplete si osobní a serverový certifikát.
-
j (neregistrovaný)
I tupec jako jirsak kterej placa zcela z cesty by moh aspon tusit, ze serveru je zcela uprdele jakej certifikat se pouzije, maximalne tak vyskoci hlaseni nekam do logu, ze nejde o certifikat urceny pro server.
A jelikoz je zaroven rec i o sifrovani komunikace klientem, tak by i jirsak moh tusit, ze pro takovy ucel je takovy certifikat zcela spravny a korektni (zcela bez ohledu na to, co si plka stat/"autorita" ve svych pravidlech).
Nehlede na to, ze jaksi ty statem certifikovane autority v zadnem pripade nevydavaji zadne serverove certifikaty ... mozna tak maximalne jako zcela soukromou akci, na kterou se ovsem zadny statni dozor nevztahuje (to by ovsem mr Jirsak jakozto auditor taky mohl aspon tusit).
Takze jirsak necht dal resi jak je povoleny TLS bez "duveryhodnyho" certifikatu vlastne na nic, a mi vsichni ostatni, budeme vesele dal posilat maily pomoci TLS/SSL se selfsigned certifikaty, protoze nam je celkem jedno kdo je protistranou, nebot vsichni vime, ze tento typ zabezpeceni komunikace funguje jak funguje.
-
Proč věřit organizaci, která není zrovna moc závislá na ochotě zákazníků jí za její služby platit? Jaká je tu motivace chovat se čestně?
Proč mít mezi důvěryhodnými certifikačními autoritami nějaké, které se používají jen na pár webů, které nejspíš nikdy nebudu potřebovat? A proč důvěřovat třeba čínské vládě?
-
hugochavez (neregistrovaný)
to: Filip Jirsak
o tom jak to "interne" chodi u "statem uznanych CA" se muzete dovzdelat zde: http://www.youtube.com/watch?v=XCjoJePnRBY
pripadne zde http://www.youtube.com/watch?v=ibF36Yyeehw -
P (neregistrovaný)
Jestli mi něco neuniká, tak pokud se použije šifra s (EC)DHE, tak samotné pozdější prozrazení soukromého klíče nestačí k prolomení šifry. Diffie-Hellman tam zajišťuje perfect forward secrecy a jen soukromý klíč nestačí k dešifrování komunikace. K tomu by bylo nutné znát ještě klíč vyjednaný Diffie-Hellman výměnou, což z odposlechnuté komunikace nelze.
Nebo mi něco uniká? -
hugochavez (neregistrovaný)
to P: Myslim ze ti neuniklo nic- jeto tak jak rikas. Pri pouziti DHE (Diffie-Helman-Ephemeral) ani prozrazeni pocatecniho klice neznamena zkompromitovani cele nasledujici (odposlechnute) komunikace. Pokud vladnes anglinou tak tady to rozebiraji https://www.grc.com/securitynow.htm
--> Episode #411 | 03 Jul 2013 | 103 min. Listener Feedback #171
Myslim ze jeto nak ke konci= odpovidaj tam na otazky posluchacu a 1 z nich je prave ta tvoje. Pokud davas prednost psanemu textu tak tady je prepis celeho podcastu
https://www.grc.com/sn/sn-412.htm
=jeto lepis na vyhledavani :o) takze zadej jen DHE anebo Ephemeral a jses tam kde potrebujes. -
hugochavez (neregistrovaný)
Zrejme jsem se prehlid' = ten podcast ohledne DHE na kterej odkazuju je tento:
Episode #412 | 10 Jul 2013 | 95 min.
SSL & Perfect Forward Secrecy - link na prepsanej text podcastu je ale spravne=
https://www.grc.com/sn/sn-412.htm
staci dat ve FF vyhledavavni v textu a treba ECDHE a jses kde potrebujes! ;o)
Omlouvam se za prehmat. -
Filip JirsákStříbrný podporovatel
Jenže pak by celé SSL bylo skoro k ničemu. Útočník MITM by prostě použil svůj certifikát – a nebylo by jak se MITM útoku bránit.
Problém není v tom, že se po STARTTLS vyžaduje důvěryhodný certifikát, problém je v tom, že není snadné pro některé domény SSL vynutit. Na webu se to řeší poučením uživatelů „do banky jedině přes HTTPS“, bude potřeba umět stejně instruovat i SMTP klienty. Ideální by bylo mít na to příznak v DNS (a pak už tam rovnou může být i ten certifikát…).
-
Za současné situace každopádně odmítnutí nedůvěryhodného certifikátu při komunikaci mezi servery, které se neznají, ničemu nepomůže. Protože nemá smysl dělat MITM, stačí udělat něco jako stripSSL a projde to. Aktivní útok je tak jako tak možný, pasivnímu útoku (v případě bezpečnosti použitých šifer apod.) zabrání i self-signed certifikát.
-
Filip JirsákStříbrný podporovatel
Kdyby dnes ten protokol fungoval tak, že neúspěšný pokus o navázání SSL spojení nevadí, bude se později muset vytvářet ještě další protokol, který bude odolný i proti MITM.
Se současnou implementací ale má odesílatel možnost volby. Pokud chce někam e-maily posílat bezpečně, povolí pro danou doménu jenom SSL, případně zafixuje CA certifikátu příjemce nebo rovnou jeho certifikát. Pokud použití SSL nevyžaduje, měl by si klient neúspěšné pokusy o navázání SSL nějakou dobu pamatovat a při opakovaném posílání SSL nenavazovat.
Je to stejné, jako u HTTPS. Tam také uživatel řekne, že vyžaduje HTTPS, prohlížeč se pokusí navázat bezpečné HTTPS spojení, a pokud to nejde, měl by uživateli dát na výběr, zda pokračovat i s nezabezpečeným HTTPS nebo HTTP. Akorát u toho e-mailového klienta nevolí uživatel dodatečně, ale spíš správce předem určí pravidla.
-
Filip JirsákStříbrný podporovatel
V Postfixu se to myslím dá nastavit v
smtp_tls_policy_maps. I s tím požadavkem na konkrétní otisk klíče. -
Certifikáty v DNS řeší protokol DANE, ale ten se musí nejprve dostat do všeho softwaru, do povědomí lidí a musí na něj všichni přejít. Pak toto všechno bude mnohem jednodušší a nezávislé na certifikačních autoritách. Ale to bude ještě mnoho let nebo desítek let trvat. Mezitím se musíme spokojit alespoň s něčím.
-
V Postfixu nedávno přibyla podpora pro TLSA záznamy z DANE, ale zatím je to v alpha fázi. Jsou zmíněny i v README - http://www.postfix.org/TLS_README.html.
Zatím bych DANE/TLSA podporu v Postfixu bral jako experimentální, protože její autor Viktor Dukhovni si vymyslel, že reinterpretuje RFC 6698 "trochu podle svého" - např. zaměňuje certificate usage 0 a 2.
Existence TLSA záznamu ještě neznačí, že se musí TLS použít (na to bohužel zatím žádný záznam neexistuje).
-
Jenda (neregistrovaný)
„Jenže pak by celé SSL bylo skoro k ničemu. Útočník MITM by prostě použil svůj certifikát – a nebylo by jak se MITM útoku bránit.“
Já se pozastavoval nad tím, že když útočník podvrhne svůj certifikát, tak se spojení přeruší, ale když prostě smaže z capabilities "STARTSSL", tak se mu e-mail vesele pošle.
„Problém není v tom, že se po STARTTLS vyžaduje důvěryhodný certifikát, problém je v tom, že není snadné pro některé domény SSL vynutit.“
S tím jednoznačně souhlasím.
„Na webu se to řeší poučením uživatelů „do banky jedině přes HTTPS““
Ještě by to chtělo „do banky jedině přes HTTPS a pozor na certifikát…“.
„Ideální by bylo mít na to příznak v DNS (a pak už tam rovnou může být i ten certifikát…).“
Přesně tak.
-
Filip JirsákStříbrný podporovatel
Já se pozastavoval nad tím, že když útočník podvrhne svůj certifikát, tak se spojení přeruší, ale když prostě smaže z capabilities "STARTSSL", tak se mu e-mail vesele pošle.
Je to sice nelogické, ale když vedle sebe dáte požadavek na bezpečné TLS a zpětnou kompatibilitu (nešifrované SMTP), vyjde z toho tohle. Jiná řešení jsou ještě nelogičtější, proto tohle vyhrálo.
-
Filip JirsákStříbrný podporovatel
Zvýší. Dáte klientovi možnost rozhodnout se, co dál – zda pošle e-mail i přes nezabezpečené spojení, nebo zda bude trvat na TLS. Případně se klient může učit – pokud jednou bude se serverem komunikovat přes TLS, zapamatuje si to, a příště ho bude vyžadovat.
-
Filip JirsákStříbrný podporovatel
Povolení komunikace přes nezabezpečené spojení je přímo součást protokolu. Dost podstatná součást, zpětná kompatibilita byla určitě jeden z klíčových požadavků na zabezpečený protokol. Ostatně, pokud někdo nevyžaduje zpětnou kompatibilitu, může rovnou použít XMPP nebo třeba HTTPS.
-
Jenda (neregistrovaný)
Nechápu. Dokážete vymyslet nějaký attack vector, který půjde provést v konfiguraci (1), ale nepůjde provést v konfiguraci (2)?
(1) Poštovní server pošle mail ve všech třech případech (protistrana nepodporuje STARTTLS, protistrana má nedůvěryhodný certifikát, protistrana má důvěryhodný certifikát)
(2) Poštovní server pošle mail pouze pokud protistrana nepodporuje STARTTLS nebo protistrana má důvěryhodný certifikát; pokud protistrana má nedůvěryhodný certifikát, mail nepošle
-
j (neregistrovaný)
Ale ne ... sak se podivej na jirsakovo argumentaci ... ty si prece myslis, ze v pripade ze protistrana pouzije nejaky certifikat, ze jde o zcela konkretni protistranu ... sice nevim proc by sis to mel myslet, ale jirsak si to zjevne tak predstavuje ... mno a protoze ja jako utocnik te chci presvedcit o tom, jak moc sem duveryhodnej, tak si vygeneruju certifikat mno.... spokojenost bude oboustrana ... nebo ne? ;D
Me by zajimalo, jestli taky jirsak pri kazdym spojeni overuje OCSP (pokud teda aspon tusi vocogo) ... a pokazdy, kdyz srv neodpovi (=tak 50% pripadu ...) odmitne mail prijmout, bez ohledu na platnost certifikatu. Protoze to je jedinej spravnej a bezpecnej pristup.
-
j (neregistrovaný)
Proto ff (by default) zrusil zobrazovani protokolu ... aby zvysil ten pocit bezpeci a aby se user nezabejval takovou zbytecnosti jako je protokol ... ;D
Certifikat v domene uz je ... a je tam uplne khownu. Ale jo, pridejme tam jeste dalsi a dalsi ... kupodivu ale existence mailserveru neni nijak podminena existenci domeny a naopak.
Navic tu uz minimalne par let existuje nastroj, kterej muze (z casti) poskytnout overeni protistrany ... a defakto nikdo ho nepouziva. jop, mluvim o SPF. Takovej ten trivialni textovej zaznam kterej rika, ktery servery sou za danou domenu opravneny odesilat maily.
Jinak (kupodivu) je mail zalozenej prave na tom, ze mi muze napsat kdokoli, aniz bych ho musel predem znat. Kdybych mel dovolit dorucovani jen tem "duveryhodnym" .. tak bych se snima nejdriv musel nejak seznamit ... abych jim moh duverovat ...
-
Jenda (neregistrovaný)
„Certifikat v domene uz je ... a je tam uplne khownu.“
Pokud by klient podporoval pinning (třeba SSH už umí, jinde nevím), tak ne.
„kupodivu ale existence mailserveru neni nijak podminena existenci domeny a naopak.“
Jako že posíláte maily na jenda@[77.87.241.77] nebo co tím myslíte?
„Navic tu uz minimalne par let existuje nastroj, kterej muze (z casti) poskytnout overeni protistrany ... a defakto nikdo ho nepouziva. jop, mluvim o SPF.“
Myslím, že řešíte úplně jiný problém. Tady se řeší odposlech, nikoli podvržení.
„Jinak (kupodivu) je mail zalozenej prave na tom, ze mi muze napsat kdokoli, aniz bych ho musel predem znat.“
No ale minimálně musí znát mailovou adresu. Nemohl by k ní znát i asymetrický klíč, kterým má zprávu zašifrovat?
-
Dane,
Viktor Dukhovni připravil draft se specifikací použití DANE pro SMTP a zároveň vyrobil funkční implementaci pro Postfix, která už je obsažena v posledním snapshotu vývojové verze 2.11.
Mám připravené PPA pro Ubuntu i s krátkým návodem, jak to zprovoznit:
https://launchpad.net/~ondrej/+archive/postfix+daneO.
