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í
×

19.1. 18:55 | Komunita

NHSbuntu (Joinup, prezentace) měla být z Ubuntu vycházející linuxová distribuce přizpůsobená pro potřeby britské Národní zdravotní služby (NHS). NHS se název nelíbil, nejednalo se o oficiální projekt NHS, a proto bylo NHSbuntu v září loňského roku přejmenováno na NHoS. Vývojáři NHoS tento týden oznámili, že NHS se nelíbí ani název NHoS a už nemají sílu na další přejmenování a pokračování v projektu. Dodávají, že několik jednání s vedením

… více »
Ladislav Hagara | Komentářů: 2
19.1. 18:44 | Pozvánky

Koncem ledna, 29. 1. 2018 od 17 do 20 hodin se v Akademii CZ.NIC uskuteční večer s Turrisem.

Co bude na programu?… více »
Miška | Komentářů: 4
19.1. 18:33 | Pozvánky

Na tri dni sa hlavné mesto Slovenska po tretíkrát zmení na miesto s najväčšou koncentráciou profesionálnych programátorov, systémových administrátorov, učiteľov informatiky aj technologických nadšencov. Hlavným lákadlom bude konferencia PyCon SK 2018, určená záujemcom o Python, jeden z najpopulárnejších programovacích jazykov na svete.

… více »
RicCo386 | Komentářů: 1
19.1. 18:22 | Pozvánky

Letošní ročník konference Prague PostgreSQL Developer Day se koná ve dnech 14. 2. a 15. 2. 2018. Zveřejněn byl program s přednáškami a školeními. Otevřena byla také registrace na konferenci.

TomasVondra | Komentářů: 0
19.1. 11:33 | Komunita

Společnost Canonical stojící za linuxovou distribucí Ubuntu oznámila dostupnost nástroje pro týmovou spolupráci Slack (Wikipedie) ve formátu snap. Instalovat jej lze ze Snapcraftu. Slack pro Linux je dostupný také ve formátu klasických balíčků pro Ubuntu a Fedoru.

Ladislav Hagara | Komentářů: 10
18.1. 17:33 | Nová verze

Po roce vývoje od vydání verze 2.0 a 6 000 změnách byla vydána nová stabilní verze 3.0 softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem, Wine (Wikipedie). Z novinek lze zdůraznit například podporu Direct3D 10 a 11. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 14
18.1. 13:44 | Zajímavý projekt

V říjnu loňského roku úspěšně skončila kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů. Společnost Purism informuje o aktuálním vývoji tohoto telefonu. Místo plánovaného SoC i.MX6 by měl být použit úspornější i.MX8.

Ladislav Hagara | Komentářů: 4
18.1. 12:33 | Zajímavý projekt

V květnu loňského roku měl na YouTube premiéru krátký animovaný film Agent 327: Operation Barbershop. Blender Animation Studio včera zveřejnilo alternativní konec tohoto filmu.

Ladislav Hagara | Komentářů: 0
18.1. 05:55 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 237 bezpečnostních chyb. V Oracle Java SE je například opraveno 21 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 18 z nich. V Oracle MySQL je opraveno 25 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 6 z nich.

Ladislav Hagara | Komentářů: 0
17.1. 20:55 | Komunita

Linux ve VirtualBoxu nebude potřebovat Přídavky pro hosta (Guest Additions). Budou součástí linuxového jádra. Ovladač vboxguest by se měl dostat do Linuxu 4.16. Ovladač vboxsf by měl následovat.

Ladislav Hagara | Komentářů: 27
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (7%)
 (1%)
 (1%)
 (1%)
 (77%)
 (13%)
Celkem 1350 hlasů
 Komentářů: 53, poslední 17.1. 16:55
    Rozcestník

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

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

    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.