DKIM - zavádíme podpisovou politiku (ADSP) (diskuse)

[pet]

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"

[flexo]

č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.

[trekker.dk]

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.

[xkucf03]

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.

[Karel]

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!

[Hobil]

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.

[Heron]

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).

[Ondar]

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]

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.

[Luboš Kašpar - posmaster-at-cnb.cz]

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.

[Sapo]

V pripade ze server dela navic relay pro jinou domenu to funguje jak ? Predpokladam ze se email posle dale a nic se nepodepisuje ?