abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

16.11. 23:44 | IT novinky

Společnosti Dell a Canonical společně představily 5 nových počítačů Dell Precision s předinstalovaným Ubuntu. Jedná se o 4 notebooky a 1 all-in-one počítač. Cena počítačů s Ubuntu je o 100 dolarů nižší než jejich cena s Windows 10.

Ladislav Hagara | Komentářů: 8
16.11. 22:55 | Nová verze

Po pěti měsících vývoje od vydání verze 4.8 byla vydána nová verze 4.9 svobodného open source redakčního systému WordPress. Kódové označením Tipton bylo vybráno na počest amerického jazzového muzikanta a kapelníka Billyho Tiptona.

Ladislav Hagara | Komentářů: 0
16.11. 22:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 146. brněnský sraz, který proběhne v pátek 17. listopadu od 18:00 hodin v restauraci Bogota na Nových Sadech.

Ladislav Hagara | Komentářů: 0
16.11. 21:55 | Nová verze

Dle plánu byla vydána nová verze 9.2.1 živé linuxové distribuce Slax. Novinkou je především přechod ze Slackware na Debian a z KDE na Fluxbox.

Ladislav Hagara | Komentářů: 2
15.11. 22:44 | Zajímavý projekt

Vítězným projektem letošního ročníku soutěže určené vývojářům open source hardwaru Hackaday Prize se stal podvodní kluzák (YouTube, Onshape). Cenu za nejlepší produkt získala braillská klávesnice pro chytré telefony Tipo (YouTube).

Ladislav Hagara | Komentářů: 0
15.11. 06:33 | Nová verze

Byla vydána verze 3.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Řešena je také řada bezpečnostních problémů.

Ladislav Hagara | Komentářů: 3
15.11. 00:11 | Nová verze

Byla vydána beta verze Linux Mintu 18.3 s kódovým jménem Sylvia. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.3 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
14.11. 21:44 | Nová verze

Byla vydána verze 5.2.0 svobodného integrovaného vývojového prostředí KDevelop. Přímo z menu KDevelopu lze nově analyzovat aplikace napsané v C/C++ pomocí nástroje Heaptrack. Vylepšena byla podpora programovacích jazyků C++, PHP a Python. Ke stažení a k vyzkoušení je binární balíček s KDevelopem 5.2.0 ve formátu AppImage.

Ladislav Hagara | Komentářů: 8
14.11. 17:33 | Nová verze

MojeFedora.cz informuje, že bylo oficiálně oznámeno vydání Fedory 27. Ve finální verzi vycházejí dvě edice: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server vzhledem k náročnosti přechodu na modularitu vychází pouze v betaverzi a finální verze je naplánována na leden. Vedle nich jsou k dispozici také alternativní desktopy v podobě KDE Plasma, Xfce a další a k tomu laby – upravené vydání Fedory například pro designery, robotiku, vědecké použití atd. Stahovat lze z Get Fedora.

Ladislav Hagara | Komentářů: 21
14.11. 17:22 | Pozvánky

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tradičně první čtvrtek před třetím pátkem v měsíci: 16. listopadu od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).

xkucf03 | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (73%)
 (14%)
Celkem 679 hlasů
 Komentářů: 36, poslední včera 18:43
    Rozcestník

    DKIM – zavádíme podpisovou politiku (ADSP)

    5. 10. 2010 | František Kučera | Bezpečnost | 5421×

    Dnes volně navážeme na článek o DKIMu, ve kterém jsme naučili náš poštovní server podepisovat e-maily, a povíme si něco o ADSP (Author Domain Signing Practices), pomocí kterého říkáme ostatním serverům, jaká je podpisová politika naší domény.

    Co je ADSP a co nám přinese

    Samotné podepisování odchozích e-mailů a jejich ověřování serverem příjemce (DKIM) je sice hezké, ale nemá skoro žádné praktické přínosy – snad jen to, že ve webovém rozhraní GMailu se příjemci zobrazí: podepsáno od naše-doména.cz nebo že si pokročilý uživatel může zobrazit zdrojový kód zprávy a v něm zkontrolovat hlavičku Authentication-Results.

    Praktických přínosů se dočkáme až po nasazení technologie ADSP, která na DKIM navazuje. ADSP je způsob, kterým vlastník domény může sdělit světu, jak je to s podepisováním jeho e-mailů. Na výběr má tři možnosti:

    • unknown – neznámá politika, některé e-maily z domény mohou být podepsané, jiné ne. Tomu, zda jsou dopisy podepsané nebo nepodepsané, nebudeme přikládat žádnou váhu.
    • all – všechny dopisy z dané domény jsou podepsané. E-maily, kterým podpis chybí jsou podezřelé a příjemce je může podrobit přísnější kontrole – ale neměl by je zahodit/odmítnout jen na základě toho, že jim chybí podpis.
    • discardable – všechny dopisy z dané domény jsou podepsané. A pokud ne, je doporučeno je zahodit – „the domain encourages the recipient(s) to discard it“

    K čemu je tedy zavedení ADSP dobré?

    Jako příjemce e-mailů se můžeme zbavit části spamu – nevyžádané pošty. Nepodepsané e-maily tvářící se být z domény, která má discardable politiku můžeme klidně zahodit/odmítnout a nemusíme jimi zatěžovat své uživatele. Bohužel se zbavíme jen části spamu, protože spameři často využívají zavirovaných klientských počítačů (typicky s Windows), ze kterých uživatelům ukradnou jejich jméno a heslo – a spam odesílají pomocí nich, takže může mít platný DKIM podpis. Přínos je ale každopádně v tom, že víme, z jakého serveru spam pochází a vlastník tohoto serveru ví, přes který uživatelský účet byl odeslán – je tak možné danému uživateli zablokovat SMTP, nastavit mu kvótu na odchozí e-maily nebo ho vyzvat k nápravě (odvšivení počítače).

    Nastavením discardable politiky se jako vlastník domény budeme bránit rhybaření resp. podvodným dopisům. Nikdo pak nebude moci posílat e-maily, které se tváří, jako že jsou z naší domény. Alespoň ne na servery, které respektují ADSP politiku ostatních domén. Toho využívá např. platební systém PayPal.com. Nasazením ADSP na straně serveru příjemce ochráníte své uživatele před těmito podvodnými e-maily.

    Nasazení v praxi

    Podepisování e-mailů máme zprovozněné už od minule, teď se proto budeme soustředit jen na změny související s nasazením ADSP, nikoli samotného DKIMu.

    DNS – na straně odesílatele

    Jako vlastník internetové domény si definujeme ADSP politiku – to je velice jednoduché, stačí vytvořit příslušný DNS TXT záznam pro naši doménu:

    _adsp._domainkey.example.com. IN TXT "dkim=discardable"

    Místo discardable můžeme použít mírnější all (viz význam politik výše). Politiku unknown nemá moc smysl nastavovat, protože stejně se interpretuje, i když ADSP záznam úplně chybí.

    DKIM Milter – na straně příjemce

    Pro ověřování podpisů a souladu s ADSP politikou použijeme stejný software jako pro podepisování odchozích zpráv: DKIM Milter (viz předchozí článek). Jediné, co musíme udělat, je upravit konfigurační soubor /etc/dkim-filter.conf – přidáme do něj řádek:

    ADSPDiscardyes

    A restartujeme filtr:

    /etc/init.d/dkim-filter restart

    Po této úpravě bude náš server respektovat ADSP politiky ostatních domén a pokud se někdo pokusí odeslat nepodepsaný e-mail z domény, která o sobě tvrdí, že všechny její e-maily mají být podepsané, bude naším serverem odmítnut.

    Poznámka: někdy můžeme narazit na výchozí konfigurační soubor dkim-filter.conf, který obsahuje chybný řádek #ASPDiscardno místo správného #ADSPDiscard no – dáváme tedy pozor na překlepy.

    DKIM/ADSP vs. SPF

    DKIM/ADSP a SPF (Sender Policy Framework) jsou svým způsobem konkurenční technologie – obě mají podobné cíle a obě používají DNS.

    Pro DKIM a ADSP v DNS nastavíme:

    default._domainkey.example.com. IN TXT "v=DKIM1; g=*; k=rsa; p=MIGf...wIDAQAB"
    _adsp._domainkey.example.com. IN TXT "dkim=discardable"

    A pro SPF:

    example.com. IN TXT "v=spf1 mx ip4:146.102.….… ~all"

    V obou případech definujeme v DNS záznamech jednak podmínky (u DKIM je to veřejný klíč, kterým mají být zprávy podepsané, u SPF jsou to IP adresy, ze kterých mohou e-maily odcházet) a jednak politiku, která říká, co se má dělat se zprávami, které podmínky nesplňují.

    SPF je sice jednodušší (není potřeba pracovat s kryptografií – stačí zkontrolovat IP adresu), ale trpí docela zásadním problémem při přeposílání zpráv. Když si uživatel nechá přeposílat e-maily z jednoho účtu na druhý, zprávy z domény odesílatele najednou odcházejí z jiné IP adresy a cílový server nemůže poznat, zda se jedná o přeposílání nebo třeba o spam. DKIM/ADSP tímto problémem netrpí, protože elektronický podpis lze ověřit i u přeposlané zprávy – je jedno, odkud přišla, pokud je podpis platný. SPF navrhuje, aby se u přeposílaných zpráv měnila adresa odesílatele (použít tzv. remailing a ne forwarding), nebo aby si příjemci přidali přeposílající servery na bílou listinu. To ovšem vyžaduje provést změny na všech přeposílajících nebo cílových serverech, což činí ze SPF politiky -all (e-maily mohou odcházet jen z vyjmenovaných IP adres a žádných jiných) prakticky nepoužitelnou záležitost. Tuto politiku má nastavanou např. Česká národní banka (cnb.cz). Takže pokud vám bude psát někdo z ČNB a vy si necháváte e-maily přeposílat na server, který respektuje SPF politiku, zpráva k vám nedorazí. Když vám naopak bude psát PayPal (který má nastavenou DKIM politiku discardable), e-mail k vám dorazí, i když si ho přepošlete třeba desetkrát.

    Modelová situace

    Mějme tři poštovní servery resp. domény:

    • a.tld – tato doména má nastavenou přísnou ADSP politiku, která říká, že všechny e-maily z této domény musí být podepsané, jinak se mají odmítat – tzn. má v DNS nastavený záznam: _adsp._domainkey.example.com. IN TXT "dkim=discardable"
    • b.tld – poštovní server této domény má podporu DKIM a je nastaven tak, aby respektoval ADSP politiku domény odesílatele. V praxi to znamená, že je na serveru např. Postfix a dkim-filter s nastavenou volbou ADSPDiscard yes.
    • c.tld – libovolný jiný server, který použijeme pro odeslání zprávy.

    První případ – podvrh

    Uživatel s adresou uzivatel@a.tld se pokusí odeslat e-mail ze své adresy pomocí nikoli svého domácího serveru (a.tld), ale pomocí jiného serveru (c.tld – např. server v práci nebo ve škole). Server c.tld nemá soukromý klíč domény a.tld a odchozí e-maily samozřejmě nepodepisuje.

    1. Uživatel se pokusí poslat e-mail z adresy uzivatel@a.tld pomocí serveru c.tld na adresu uzivatel@b.tld. SMTP server c.tld jeho požadavek přijme – zařadí zprávu do fronty a ukončí SMTP spojení.
    2. Server c.tld se pokusí předat zprávu serveru b.tld, ten si ale pomocí DNS dotazu zjistí ADSP politiku domény odesílatele (a.tld), která říká, že nepodepsané e-maily z této domény se mají odmítat. Server b.tld tedy odmítne přijetí zprávy ještě v rámci dané SMTP relace – zprávu vůbec nepřijme a v logu serveru c.tld najdeme záznam podobný tomuto:

      Sep 24 13:31:13 vse postfix/smtp[22720]: [ID 197553 mail.info] 8DC611802: to=<uzivatel@b.tld>, relay=b.tld[2a01:430:...::...]:25, delay=1.3, delays=0.01/0/0.63/0.65, dsn=5.7.1, status=bounced (host b.tld[2a01:430:...::...] said: 550 5.7.1 rejected due to DKIM ADSP evaluation (in reply to end of DATA command))

    3. Server c.tld odesílání zprávy vzdá, zabalí ji do obálky a pošle jako nedoručitelnou na adresu odesílatele – uzivatel@a.tld dostane typický e-mail s předmětem Undelivered Mail Returned to Sender. Zpráva se tedy neztratí, nezahodí – odesílatel okamžitě zjistí, že nebyla doručena a proč – může ji tedy odeslat znovu, tentokrát pomocí správného SMTP serveru. Pokud by se jednalo o podvrh – útočník by se snažil odeslat zprávu z adresy uzivatel@a.tld – uživatel by na to díky této chybové zprávě přišel (v ní by byl přiložen i přímo ten e-mail, který se útočník jeho jménem pokoušel odeslat).

    Druhý případ – přeposílání

    Uživatel má dvě adresy: uzivatel@c.tld a uzivatel@b.tld. Poštu z c.tld si nečte na tomto serveru, ale nechá si ji přeposílat na server b.tld.

    1. Odesílatel uzivatel@a.tld pošle zprávu pomocí serveru a.tld na adresu uzivatel@c.tld. Server a.tld podepíše zprávu.
    2. Server c.tld zprávu přijme a včetně podpisu ji předá serveru b.tld
    3. Server b.tld ověří podpis a ADSP politiku a zprávu přijme – nezajímá ho, z jakého serveru k němu zpráva fyzicky dorazila (c.tld místo a.tld), důležité je, že zpráva má správný DKIM podpis.

    Při použití technologie DKIM/ADSP tedy nemáme problémy s přeposíláním, jako je tomu u SPF.

    Na co nezapomenout

    Možná se teď chystáte nadšeně nastavit ADSP politiku pro svoji doménu, před tím je ale dobré se ještě zamyslet nad následujícími případy:

    • Odchozí e-maily z našich www serverů – řada webových serverů posílá např. registrační e-maily nebo zapomenutá hesla uživatelům. Pokud nepoužíváme centrální poštovní server, ale běží nám na tom webovém samostatný SMTP server, který komunikuje s okolním světem přímo, nesmíme ani tento server zapomenout vybavit DKIM klíči a podepisovat na něm e-maily. Totéž platí pro všechny ostatní systémy, které posílají zprávy – různé helpdeskové aplikace, systémy na správu požadavků, měřáky dostupnosti atd.
    • Hromadné e-maily posílané třetí stranou – zajišťuje pro vás marketing nebo rozesílání e-mailového zpravodaje nějaká externí firma? Pak jí musíte říct, aby zprávy podepisovala a její klíč přidat do DNS vedle těch svých, nebo jí dát přístup na svůj SMTP server (to už si to můžete posílat sami), případně takové hromadné e-maily posílat z jiné domény – např. marketing.example.com, která bude mít benevolentní podpisovou politiku.
    • E-maily z cizích webových formulářů – mnoho webů umožňuje pomocí vlastního formuláře poslat kamarádovi např. odkaz na článek nebo pozvánku. Uživatel jednoduše vyplní svoji a příjemcovu adresu a odešle formulář. Takový e-mail se pak tváří, jako že je z naší domény, ale samozřejmě nemá potřebný podpis. Své uživatele (zaměstnance, studenty atd.) musíte v případě přísné ADSP politiky upozornit, že takto e-maily odesílat nemohou (stejně jako je upozorníte, že nemohou použít např. SMTP server domácího poskytovatele). Pokud naopak sami takové formuláře vytváříte, zkuste je navrhnout lépe – tak, aby se zprávy odesílaly z vaší domény a měly nastavenou hlavičku Reply-To na adresu, kterou zadal uživatel – zpráva bude bezproblémů doručena (protože bude z vaší domény a vašeho sevreru) a pokud na ni bude chtít příjemce odpovědět, odpoví na adresu odesílatele.

    Jakou politiku zvolit?

    V případě firem lze doporučit discardable politiku. Zřejmě nestojíte o to, aby zaměstnanci posílali firemní (důvěrnou) poštu přes nějaké pochybné cizí SMTP sevrery – když už mají mít přístup k e-mailu i mimo firmu, tak jim poskytnete přístup na svůj SMTP server, webové rozhraní k poště nebo třeba VPN. Díky ADSP snížíte pravděpodobnost, že bude někdo vaším jménem (z vaší domény) posílat např. falešné faktury nebo nějaké poplašné zprávy.

    Pokud naopak spravujete školní nebo nějaký komunitní server nebo jste poskytovatelem e-mailových služeb, není discardable politika moc dobrou volbou. Těžko donutíte uživatele, aby posílali e-maily výhradně přes váš SMTP server – a ani to není žádoucí – uživatelé by pak asi danou e-mailovou adresu přestali používat. Přesto je dobré nasadit DKIM a podepisovat e-maily – v případě nějakých incidentů půjde např. dohledat, zda daný e-mail odešel z vašeho serveru. Také tím zvýšíte důvěryhodnost odchozích e-mailů – zde záleží na podpoře klientského softwaru – ten může uživateli signalizovat, že e-mail obsahuje platný DKIM podpis (jako to dělá např. GMail).

    Je SPF na nic?

    SPF není na nic, jen jeho politika -all je takřka nepoužitelná. Klidně ale můžete nastavit ~all politiku, která říká, že e-maily odeslané z jiných IP adres mají být přijaty, jen mohou být podrobeny důkladnější kontrole. Naopak zprávy přijaté z vyjmenovaných IP adres budou důvěryhodnější.

    Ještě jedno dobré využití má SPF: existuje poměrně dost domén, které se používají jen pro web nebo jiné služby, ale nikdy z nich žádné e-maily neodcházejí. U takových domén nastavíme -all SPF politiku a tím zabráníme spamerům, aby naši doménu zneužívali jako odchozí. Totéž můžeme udělat s ADSP – nastavíme discardable politiku (pro případ, že server příjemce podporuje ADSP, ale nepodporuje SPF).

    Jak se chovat na straně příjemce

    Jako správci serveru přijímajícího poštu bychom měli respektovat politiky (jak ADSP, tak SPF), které si nastavili vlastníci jiných domén. Pokud někdo tvrdí: „všechny naše e-maily jsou podepsané tím a tím klíčem“, tak to berme jako fakt – a to i v případě, že by se nám jeho politika mohla zdát příliš přísná nebo špatná – jsou to jeho e-maily a jeho případná odpovědnost a chyba – ne naše. Navíc pokud si poštovní systém nastavíme tak, jak je uvedeno v návodu výše, nevyhovující e-maily budou odmítnuty ještě v rámci SMTP spojení (ne až následně), takže se žádné zprávy neztratí – e-mail se jednoduše vrátí ke svému odesílateli jako nedoručitelný.

    Závěr

    DKIM a ADSP je přínosná technologie, která pomáhá v boji se spamem a podvodnými e-maily – i když samozřejmě nedokáže tyto problémy vyřešit zcela. Ideální by bylo, kdyby e-maily podepisovali sami uživatelé (ať už pomocí OpenPGP/GPG nebo S/MIME) a také je šifrovali, ovšem vzhledem k neschopnosti běžných uživatelů tyto technologie používat je fajn podepisovat zprávy alespoň na úrovni domény. Ruku na srdce: kolik už jste zaplatili faktur, které k vám dorazily nešifrovaným a nepodepsaným e-mailem nebo dokonce papírovou poštou?

    Odkazy

           

    Hodnocení: 75 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    5.10.2010 07:52 pet
    Rozbalit Rozbalit vše První případ – podvrh

    Pokud by se jednalo o podvrh – útočník by se snažil odeslat zprávu z adresy uzivatel@a.tld – uživatel by na to díky této chybové zprávě přišel (v ní by byl přiložen i přímo ten e-mail, který se útočník jeho jménem pokoušel odeslat).

    Jinými slovy: nespamujete příjemce, ale "odesílatele" :-(

    5.10.2010 08:40 flexo
    Rozbalit Rozbalit vše Re: První případ – podvrh
    článek mi přistál v rss čtečce, chtěl sem si ho přečíst, ale odkaz vede na http://www.abclinuxu.cznull/. Prosím jestli je to chyba u Vás, tak to opravte. Díky. Teď si to du přečíst.
    5.10.2010 10:28 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: První případ – podvrh
    Jinými slovy: nespamujete příjemce, ale "odesílatele"
    To většinou nebude pravda: pokud je mail odmítnut už v SMTP relaci - v uvedeném příkladu to tak podle všeho je - pak není pravděpodobné, že by se rozesílající spamovací vir obtěžoval s tím zasílat zprávu o nedoručitelnosti.
    Quando omni flunkus moritati
    xkucf03 avatar 5.10.2010 13:47 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: První případ – podvrh
    1. K odmítnutí dojde ještě v rámci SMTP spojení (záleží na nastavení, ale podle toho uvedeného v článku ano), takže je zpráva vrácena přímo útočníkovi – nedostane se ani do poštovní fronty. Pokud se útočníkovi/spamerovi podaří zprávu procpat do poštovní fronty nějakého jiného serveru, který se ji staží předat na ten cílový, k odeslání chybové zprávy falešnému příjemci dojde – ale problém vznikl už ve chvíli, kdy se mu podařilo ten mail procpat už na ten první server (ne až ve chvíli, kdy nastoupil DKIM a ADSP).
    2. Je to podobná situace jako když je příjemcem neexistující adresa – lepší řešení to moc nemá – máme totiž jen dvě možnosti: odeslat chybovou zprávu a otravovat nevinné lidi nebo ji neodeslat s tím, že nějaký důležitý e-mail prostě ztratí. V případě DKIM/ADSP by ten systém šlo nastavit i tak, aby se žádné chybové zprávy neposílaly a nepodepsané e-maily se prostě zahazovaly – ale to vyžaduje poměrně vysokou disciplínu na straně odesílatele – musí podepisovat vše a když omylem pošle nepodepsaný e-mail (třeba použije jiný SMTP server nebo na tom jeho bude chyba), nedozví se o tom a může se ztratit nějaká důležitá zpráva.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    5.10.2010 23:13 Karel
    Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)
    Stejne je tohle podepisovani mailu na serveru na nic - maily maji podepisovat uzivatele a maji mit nejaky certifikat podepsany CA - tim se teprve zbavime spamu!
    6.10.2010 16:57 Hobil | skóre: 1 | blog: Hobilovo_doupe
    Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)
    Nezbavis. Pokud se pocitac stane soucasti botnetu (napr. "diky" nejakemu rootkitu), posila zpravy i s (legalnim) podpisem.

    Vidim to spis jako riziko pro uzivatele - pri nabourani pocitace ziska utocnik nejen jeho pocitacovy vykon, ale take jeho e-identitu. H.
    Aktualni top neni 0.9, anobrz 3.2.8. Top 0.9 je beznadejne zastaraly.
    Heron avatar 6.10.2010 17:31 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)

    Nezbavíme

    1) Nikdy nepřinutíš všechny něco dělat.
    2) Spamerovi nic nebrání to posílat podepsané (jak už bylo řečeno).

    11.10.2010 13:22 Ondar | skóre: 25 | blog: Linux_blog
    Rozbalit Rozbalit vše SPF
    A jeho politika -all není vůbec na nic. Spíš bych řekl, že klasickému forwardování už odzvonilo a ten kdo to dělá by se měl nad sebou zamyslet. Stačí to ponechat na uživatelích - ti pokud si u sebe třeba v TB nastaví forwarding, tak to projde v pohodě. Ne, SPF má díky své jednoduchosti pro mnoho adminů (včetně mě) pořád co říci.
    xkucf03 avatar 11.10.2010 14:16 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SPF
    Takže mi má pořád běžet desktop a na něm Thunderbird, který bude přes pomalou domácí linku ty maily posílat zase zpátky do Internetu na jiný server? Ne, děkuji nechci.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    29.12.2010 11:57 Luboš Kašpar - posmaster-at-cnb.cz
    Rozbalit Rozbalit vše Re: SPF
    Souhlas s "Ondarem" (úvodní větě rozumím tak, že SPF "-all" k něčemu je).

    Ohledně SPF článek nepracuje příliš korektně s pojmy. Pokud je zachována SMTP-obálková adresa odesilatele (z "MAIL FROM:"), jde o tzv. "bouncing", resp. "relaying" a pak mohou být "problémy"; jestliže však je odesilatel v obálce změněn, jde o "forwarding" (pojem "remailing" je poněkud svérázný a je poplatný spíš oblasti MUA než MTA). V obou případech bez ohledu na to, jak se pracuje s adresami v hlavičkách typu "From:", "Sender:" ap. V dnešní době by samozřejmě k žádnému podloudnému relayingu již docházet nemělo (na úrovni MSA je korektní forwarding), takže by neměly být ani problémy se SPF (původní obálkovou adresu odesilatele lze uložit např. do standardní hlavičky "Return-Path:").

    Zároveň si dovoluji se ohradit proti způsobu, jakým je citována SPF-politika ČNB (cnb.cz), kdy je nastavení "-all" v ní uvedeno hned za větou zcela znevažující takovou SPF-politiku. Pisatel článku také nebere ve svém stanovisku v potaz velmi důležitý fakt, že RFC 4408 (definice SPF) má status EXPERIMENTAL, tj. zatím nejde o žádný faktický standard (např. typu RFC 5321 pro SMTP), takže jeho aplikace má být podmíněna konkrétní dohodou odesilatele a příjemce. Pokud tedy příjemce odmítá maily, které odporují SPF bez dohody s odesilatelem (např. s ČNB zatím nikdo takovou dohodu ohledně cnb.cz neuzavřel), nečiní tak korektně a uživatel SPF na straně správy domény na tom nemůže mít žádnou vinu.
    16.12.2010 13:47 Sapo | skóre: 8
    Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)
    V pripade ze server dela navic relay pro jinou domenu to funguje jak ? Predpokladam ze se email posle dale a nic se nepodepisuje ?

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.