Hlavní navigace

Názory k článku DMARC: ověření odesilatelovy domény

  • Článek je starý, nové názory již nelze přidávat.
  • 23. 4. 2015 8:02

    Petr (neregistrovaný) 37.220.35.---

    A co použít na analýzu DMARC reportů? Co jsem zatím viděl tak jsou jen samé webové služby, ale já bych chtěl něco na svém serveru.

  • 23. 4. 2015 9:02

    bez přezdívky

    Celkově máme nasazeno na všech našich doménách :
    antispam, antivir, greylisting + whitelist (v případě existence SPF se greylisting neuplatňuje)
    spf, dkim, adsp, dmarc

    Přeposílání se praktikuje v rámci našeho serveru / domény, takže to neřeším a ve finále ani není moc žádoucí, aby si někdo přeposílal firemní maily někam ven na privát.

    Dobrý, přehledný a jednoduchý nástroj na reporty ohledně mailů slouží tato solidní služba :
    http://www.mail-tester.com

    V současné době máme největší problém s greylistingem, kdy většinou malé firmy mají svá řešení v cloudu, neřeší vůbec žádné zabezpečení a tak se stane, že místo toho, aby měl první mail u greylistingu 10min zpoždění, tak může mít klidně i den zpoždění, protože se uplatňuje politika :
    server + adresa odesílatele + adresa adresáta
    Náš server tedy odmítne mail, ale další pokus o doručení přijde z jiného serveru (protože cloud) a těch serverů není málo.
    Náš whitelist je celkem obsáhlý a zatím mi to přijde jako lepší řešení, než greylisting nemít (je rozdíl, zda se uživatelům doručí 10 000 mailů za den, nebo 40 000, kde 30 000 je 100% spam). A není to jen o uživatelích, je též rozdíl mít denně 30 000 emailů navíc v archivačním systému, každý den v zálohovacím systému atd.

    Shrnuto a podtrženo, problém bývá vždy v tom, že většina lidí na takové věci kašle :-/.

    Zdar Max

  • 23. 4. 2015 10:23

    Heron

    "Shrnuto a podtrženo, problém bývá vždy v tom, že většina lidí na takové věci kašle :-/."

    Zde musím kategoricky nesouhlasit. Problém je v tom, že dokolečka dokola vymýšlí systém jak udělat něco co nejde. Prostě email z definice té služby (přijímání zpráv z anonymních a dopředu neznámých odesílatelů) nelze ochránit před tím, aby nějaký anonym z neznámého serveru poslal jakousi zprávu. Nelze.

    Pokud už to není tak úplně anonymní odesílatel, tak existuje hromada mnohem lepších systémů pro zprávy (samozřejmě podepsané) a netřeba používat email.

    A toto je skutečně věc, která mě poslední roky nenechává chladným. Na ochranu něčeho, co nelze ochránit se vynakládají strašné prachy (proto se to taky dělá, že) a postupně se rozbíjí věci, které fungovaly doposud (takže se všechno neustále předělává a tím se rozbíjí zase další věci a tak to jde už hezkých pár desítek let).

  • 23. 4. 2015 10:44

    backup (neregistrovaný) ---.dip0.t-ipconnect.de

    s tim 100% souhlas. Programujeme softwarova reseni pro mensi firmy a musim konstatovat, ze komunikace mailem nahradila dnes skoro jiz uplne drivejsi faxy a dopisy. Ale uzivatele by radi meli 'jistotu', ze zprava dosla. :-) Jak pisete, zde se nasazuje nespravna technologie a jeji nedostatky se snazi cely svet nejak 'vylepsit' - s nasledky jak pisete.

    Soucasne resime napr. problem, ze na automaticky generovane maily (Net::SMTP) je na prijemcove strane nahlizeno jako na spam, zatimco ten samy mail, zaslany pres outlook projde. Takova situace je neudrzitelna.

  • 23. 4. 2015 10:51

    bez přezdívky

    Odesílací server lze ověřit (na DNS mít DNSSEC + na mail serveru DKIM).
    Teoreticky i odesílatele, pokud si mail podepíše.

    Nikdo netvrdí, že email je dokonalý, technický problém pro změnu je ten, že je všude a mají ho všichni, je to rychlé a jednoduché a má to podporu úplně ve všem. Nikdo se tedy nemůže divit, že se spousta firem snaží komunikaci vylepšovat a více zabezpečovat. Buďme realisti ;-).

    Zdar Max

  • 23. 4. 2015 11:23

    Heron

    "Nikdo se tedy nemůže divit, že se spousta firem snaží komunikaci vylepšovat a více zabezpečovat."

    Ano a tak už to jde víc jak 25 let. Při pohledu na kteroukoliv ze svých schránek (free i komerční poskytovatelé) rozhodně netrpím pocitem, že by se povedlo se spamem za těch 25 let cokoliv udělat. Co se naopak povedlo dokonale je zabránit funkci email serveru nastaveného dle platných RFC. Místo toho zůstal boj silnějšího (má to tak nastavený nějaký velký hráč, víme, že je to blbě, ale přizpůsobíme se).

  • 23. 4. 2015 11:44

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Hele ale kdyz si prelozis tu zkratku, tak ti mozna dojde proc ...

    To ze veci na netu fungujou tak, jak si je kdo nastavi, platilo zcela odjakziva.

  • 23. 4. 2015 12:02

    bez přezdívky

    Odložme to, že někdo jedná monopolně. Spíš by mně zajímalo, čím by jsi mail nahradil? Mně moc věcí nenapadá, ale to je jen tím, že v jistých věcech nejsem moc kreativní.
    Zdar Max

  • 23. 4. 2015 13:09

    Heron

    Tak já bych email snad ani nenahrazoval. Prostě bych ho nechal tak jak je, bez všech těch pičovin a zdůraznil bych, že to není služba s garantovaným provozem a garantovaným doručením.

    A pokud někdo chce, tak nad tímto systémem může vybudovat další patro a posílat si buď jen podepsané, nebo rovnou šifrované zprávy. Potom bude mít jistotu od koho to je. Zbytek zpráv může prostě zahodit.

    Mimochodem, na principu emailové infrastruktury je založena německá implementace datových schránek. Polouzavřená síť serverů a klientů a akceptují se pouze zprávy podepsané správným crt od správných autorit. (Na rozdíl od našeho proprietárního řešení za 4mld stačilo vzít stávající software a přidat do něj povinné kontroly.)

    Jinak, pokud obě strany ví s kým komunikují, tak se většinou vytvoří speciální řešení jen a pouze na míru této komunikace. Tím může být úplně klidně libovolný existující CMS software zpřístupněný pouze někomu.

  • 23. 4. 2015 13:19

    PQK

    Hmmm ... jenže právě ty "všechny pičoviny" SFP, DKIM, DMARC, DNSSEC přidávají přesně to co obbdivujete na německých datových schránkách - ke stávajícímu software přidaly kontroly.

    Pokud by se podařilo soustavným tlakem donutit všechny aby to používaly, tak jsme hodně rychle bez spamu ...

  • 23. 4. 2015 13:28

    Heron

    "Hmmm ... jenže právě ty "všechny pičoviny" SFP, DKIM, DMARC, DNSSEC přidávají přesně to co obbdivujete na německých datových schránkách - ke stávajícímu software přidaly kontroly."

    Ne, tam se jedná o uzavřený systém (není to totéž jako veřejný email), do kterého se může přidat další "licencovaný subjekt" a kontroly se týkají "formátu zpráv". Není třeba kontrolovat komunikaci mezi servery, protože ten jejich seznam je dán. (Tj jen tak pohled z rychlíku.)

    "Pokud by se podařilo soustavným tlakem donutit všechny aby to používaly, tak jsme hodně rychle bez spamu ..."

    To tedy ani omylem. Už dneska jsou některé zdroje spamu nastavené lépe (z hlediska těch vyjmenovaných technologií) než leckteré emailové servery pro uživatele. Pokud byste chtěl filtrovat podle tohoto klíče, tak vyřadíte ty hůře nastavené běžné servery a zbudou vám dobře nastavené normální servery a také dobře nastavené zdroje spamu. A jste tam, kde jste byl na počátku.

  • 23. 4. 2015 13:33

    bez přezdívky

    Jenomže ty dobře nastavené zdroje spamu můžeš triviálně odfiltrovat ;-).

    Je to podle mně jen o tom, že buď chci mít centralizované řešení, nebo decentralizované.

    Zdar Max

  • 23. 4. 2015 13:36

    Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----

    Jenomže ty dobře nastavené zdroje spamu můžeš triviálně odfiltrovat ;-).

    Tak určitě... :-DDDDDDDD

  • 23. 4. 2015 13:41

    Filip Jirsák

    Jenže provozovatel toho zdroje spamu ještě triviálněji vytvoří deset dalších zdrojů. Autorizace odesílatele je pro likvidaci spamu podmínka nutná, nikoli dostačující.

  • 23. 4. 2015 20:53

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Hodne naivni ...

    Hele, aktualne je to o tom, ze vsechny tyhle veci fugujou jen a pouze proto, ze se spamerum nevyplati to resit. Jednoduse pomer filtrujicich a nefiltrujicich MTA je tak obrovskej, ze tech par, kam se maily dorucit nepovede nema smysl resit.

    Jakmile se jim to resit vyplati, tak to prestane fungovat. Myslis si jako, ze kdyz budu vedet, ze odeslu 10g mailu a dostanu za to rekneme 10k$, tak ze me vytrhne, ze si na to musim koupit 10 domen?

  • 23. 4. 2015 20:49

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Tak to ani nahodou ... teda pokud si nechces odstrelit moznost komunikovat mailem s kymkoli kdo si precte tvoji adresu na webu/letaku/...

    Zrusis vsechny freemaily? Co myslis, jakej je problem vygenerovat miliardu freemailu, kde ten mail splni vsechny nalezitosti (bude mit radny dns, radny spf, dkim ...) a pak pres kazdej poslat 100, 1k, 10k mailu? Pak ho asi bloknou, ale porad mam poslanejch bilion mailu.

    Nechces spam? Cesta neexistuje, vzdyt spam uz rozesila i ceska posta pres DS. Jenom si za to nechava platit.

  • 23. 4. 2015 13:27

    bez přezdívky

    To je sice všechno pěkný, dost věcí se používá, dost věcí používáme na komunikaci i my. Je to vesměs automatizovaná komunikace.
    Problém tohoto je, že většinou firma potřebuje komunikovat se stovkami jiných firem, někdy i jednorázově, nebo jen po krátkou dobu. Tipicky to jsou obchodní firmy. Pro takové případy to je pak nemožné uřídit nehledě na časové prodlevy (tedy za předpokladu, že chceš decentralizované řešení).

    Tvé příklady jsou vesměs buď pro velmi omezenou společnost, u které si nějaký čas vezme "navázání komunikace" (= nastavení komunikace adminy), nebo se jedná o centralizované řešení.

    Mně by zajímalo, co by bylo špatného na tom ponechat současné emailové řešení, jen prostě vynucovat pravidla, která jsou již k mání? Co by bylo špatného na tom, kdyby se vynucovala kombinace SPF+DKIM+DMARC a zbytek zahodit?

    V takovém případě řešení pak nepotřebuješ kurvítka typu greylisting a jediný problém, který by jsi pak měl, by byl jen s provařenými účty a hesly, což by jsi měl skoro u každého řešení.

    Zdar Max

  • 23. 4. 2015 13:45

    Heron

    "Mně by zajímalo, co by bylo špatného na tom ponechat současné emailové řešení, jen prostě vynucovat pravidla, která jsou již k mání? Co by bylo špatného na tom, kdyby se vynucovala kombinace SPF+DKIM+DMARC a zbytek zahodit?"

    Je na tom špatné to, že ono "současné" řešení je skutečně současné. Včera neplatilo, zítra už bude něco nového a opět současného.

    Za posledních 25 let:

    Zákaz open relay. Do té doby se mohl email odeslat na kterýkoliv otevřený port 25. Po té už to nejde. -> Nutnost přenastavit.

    Zákaz portu 25 u ISP. Takže zákazníci museli používat pouze smtp server svého isp. -> Nutnost přenastavit.

    Zavedení SPF. Znovu si přečtěte předchozí bod ;-). Asi těžko do SPF dostanete všechny ISP uživatelů na vašem serveru. Vyřešeno submission portem o kterém dodneška nikdo neví, emaily se přece posílají protokolem HTTP, že ;-) -> Nutnost přenastavit.

    SPF dále nutí klienta pro odesílání používat jeden konkrétní server, zatímco před tím mohl klient email odeslat z jakéhokoliv serveru, kam měl přístup.

    DKIM, přiostření předchozího. Pokud by nebyl nasazen SPF, tak by si klient mohl vybrat, zda email pošle přes server domény (potom by byl podepsaný) nebo ze jiného serveru, potom by nebyl podepsaný (pěkný chaos, co?)

    Určitě jsem na hromadu věcí zapoměl, ale toto snad pro ilustraci stačí. Ke každému bodu můžu připsat, jak se to "krásně" řeší v praxi. (Například zákazník si vynutí, aby emaily posílané z vašeho systémy chodily From <user@doménaza­kaznika>. Potom k zákazníkovi přijde bývalej SEO konzultant přeorientovaný na security, a sdělí mu, že si musí nastavit SPF. Zákazník si nastaví SPF a potom volá vám, že VAŠE emaily lidi nedostávají, ale že rozhodně nemá problém na své straně, protože mu to funguje.)

  • 23. 4. 2015 15:18

    bez přezdívky

    Já jsem si celé problematiky vědom, jen pořád nevím, co místo mailu navrhuješ? Uvedl jsi nějaká centralizovaná řešení, ale sám dobře asi víš, že centralizované řešení není úplně ono a něco decentralizovaného jsi zatím nezmínil.

    Zdar Max

  • 23. 4. 2015 15:29

    Heron

    Nejsem si vědom, že bych uváděl centralizovaná řešení (naopak vždy doporučuju silně decentralizovaná peer-peer řešení). Současně jsem psal, že bych email ani nenahrazoval. Jen by bylo dobré, kdyby si ti lidé uvědomili, co email ve skutečnosti je (prostě krabice, do které kdokoliv může cokoliv hodit, což je přesně to, co ti lidé chtějí mít) a že je nemožné současně s touto definicí jakkoliv zajistit, aby do té krabice nepadaly věci, které tam nechtějí. Toť vše.

    A jestli se ti lidé napoprvé setkají v prostoru emailu a potom si zařídí vlastní komunikaci (třeba a znova opakuju: pomocí dig. podpisu a šifrování), tak proč ne? Jen bych z emailu nedělal něco, co musí vždy fungovat (protože nebude), co se vždy doručí (protože nedoručí), co se nikdy neztratí (viz všichni ti brečící lidé, co u freemailů přišli o "celou firmu"; protože určitě ztratí) apod.

  • 23. 4. 2015 15:41

    tjjdno (neregistrovaný) ---.net.upcbroadband.cz

    Jenze kdyby se datove schranky postavily nad emailem, tak by se hur zduvodnovalo proc jedna firma inkasuje tolik penez na provoz :)

    Nad emailem je postavena i komunikace ve zdravotnictvi v USA, nevim jak to maj Nemci, ale certifikaty se tam distribuuji pomoci DNS CERT RR. Minule zminovany DKIM je cpe do TXT, pry take kvuli GUI pro administraci…

  • 23. 4. 2015 21:05

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Nemci to maj pomerne jednoduse, prakticky libovolna firma se muze prihlasit jako provozovatel. Musi splnit nejaky nalezitosti (technicky a pravni), dostane prideleny nejaky klice ... a muze zacit fungovat. Pak dostava $$$ od statu per user.

    Jako user dostanes mail (kde si tusim muzes i zvolit volny jmeno dle libovule/pravidel toho kteryho provozovatele) a funguj. Provozovatel garantuje, ze maily doruci do schranky libovolnyho jinyho ucastnika vsech autorizovanych provozovatelu (coz po definovany infrastrukture neni problem zajistit).

    Pokud mi skleroza slouzi, veskera komunikace se archivuje forewer a mas k ni kdykoli pristup. Zadny ze to za 3 mesice zmizi ve stoupe. Provozovatel pochopitelne garantuje, ze to co je ve schrance je prave to, co bylo odeslano/doruceno. Tobe tim padem muze byt uprdele nejake expirovanej klic, protoze to neni tvoje starost.

    A ve finale, je co zcela ciste dobrovolny. Klidne muzes na urady chodit s lejstrem. Ale kupodivu to pouziva drtiva vetsina firem, protoze je to pro ne proste vyhodnejsi.

  • 23. 4. 2015 21:43

    tjjdno (neregistrovaný) ---.net.upcbroadband.cz

    Tak to je velmi podobny tomu americkymu reseni - tam je akreditovanej provozovatel, kterej provozuje servery (DNS s certama, SMTP kterej pred odeslanim sifruje a podepisuje dle S/MIME a na prijmu zahodi vse co neni duveryhodne podepsane). K tomu se pripoji user, pro kteryho se to tvari jako normalni email. Zadna centralni DB, pouze mnozina korenovych certu. Potvrzeni doruceni neni garantovany, kvuli tomu je tam MDN, ktery je odesilany automaticky.

  • 23. 4. 2015 11:07

    Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----

    V současné době máme největší problém s greylistingem

    Ten zhovadilej bazmek mi ani nezmiňuj...Takto to vypadá v provedení jistého maďarského freemailu, co má asi 2 miliony schránek:

    Tue 2015-04-21 18:52:10.178: 05: Attempting SMTP connection to server106.citromail.hu
    Tue 2015-04-21 18:52:10.179: 05: Resolving AAAA record for server106.citromail.hu (DNS Server: 2001:470::dead:beef)...
    Tue 2015-04-21 18:52:10.205: 05: *  server106.citromail.hu added to internal AAAA lookup black-list
    Tue 2015-04-21 18:52:10.205: 04: *  DNS server reports no valid records for the requested type found
    Tue 2015-04-21 18:52:10.205: 05: Resolving A record for server106.citromail.hu (DNS Server: 2001:470::dead:beef)...
    Tue 2015-04-21 18:52:10.206: 05: *  D=server106.citromail.hu TTL=(9) A=[91.83.45.106]
    Tue 2015-04-21 18:52:10.206: 05: Attempting SMTP connection to 91.83.45.106:25
    Tue 2015-04-21 18:52:10.206: 05: Waiting for socket connection...
    Tue 2015-04-21 18:52:10.245: 05: *  Connection established 10.0.0.10:61199 --> 91.83.45.106:25
    Tue 2015-04-21 18:52:10.245: 05: Waiting for protocol to start...
    Tue 2015-04-21 18:52:21.026: 02: <-- 220 server106.citromail.hu ESMTP spamd IP-based SPAM blocker; Tue Apr 21 18:52:10 2015
    Tue 2015-04-21 18:52:21.026: 03: --> EHLO mail.example.com
    Tue 2015-04-21 18:52:21.064: 02: <-- 250 Hello, spam sender. Pleased to be wasting your time.
    Tue 2015-04-21 18:52:21.064: 03: --> MAIL From:<test@example.com>
    Tue 2015-04-21 18:52:21.101: 02: <-- 250 You are about to try to deliver spam. Your time will be spent, for nothing.
    Tue 2015-04-21 18:52:21.101: 03: --> RCPT To:<xxxxxxxxx@citromail.hu>
    Tue 2015-04-21 18:52:21.139: 02: <-- 250 This is hurting you more than it is hurting me.
    Tue 2015-04-21 18:52:21.139: 03: --> DATA
    Tue 2015-04-21 18:52:21.176: 02: <-- 451 Temporary failure, please try again later.
    Tue 2015-04-21 18:52:21.176: 03: --> QUIT

    O 13 hodin později:

    Wed 2015-04-22 08:58:12.106: 05: Attempting SMTP connection to server106.citromail.hu
    Wed 2015-04-22 08:58:12.106: 05: *  server106.citromail.hu found in internal AAAA lookup black-list
    Wed 2015-04-22 08:58:12.106: 05: Resolving A record for server106.citromail.hu (DNS Server: 2001:470::dead:beef)...
    Wed 2015-04-22 08:58:12.106: 05: *  D=server106.citromail.hu TTL=(10) A=[91.83.45.106]
    Wed 2015-04-22 08:58:12.106: 05: Attempting SMTP connection to 91.83.45.106:25
    Wed 2015-04-22 08:58:12.106: 05: Waiting for socket connection...
    Wed 2015-04-22 08:58:12.146: 05: *  Connection established 10.0.0.10:51048 --> 91.83.45.106:25
    Wed 2015-04-22 08:58:12.146: 05: Waiting for protocol to start...
    Wed 2015-04-22 08:58:23.050: 02: <-- 220 server106.citromail.hu ESMTP spamd IP-based SPAM blocker; Wed Apr 22 08:58:12 2015
    Wed 2015-04-22 08:58:23.050: 03: --> EHLO mail.example.com
    Wed 2015-04-22 08:58:23.087: 02: <-- 250 Hello, spam sender. Pleased to be wasting your time.
    Wed 2015-04-22 08:58:23.087: 03: --> MAIL From:<test@example.com>
    Wed 2015-04-22 08:58:23.125: 02: <-- 250 You are about to try to deliver spam. Your time will be spent, for nothing.
    Wed 2015-04-22 08:58:23.125: 03: --> RCPT To:<xxxxxxxxx@citromail.hu>
    Wed 2015-04-22 08:58:23.162: 02: <-- 250 This is hurting you more than it is hurting me.
    Wed 2015-04-22 08:58:23.162: 03: --> DATA
    Wed 2015-04-22 08:58:23.239: 02: <-- 451 Temporary failure, please try again later.
    Wed 2015-04-22 08:58:23.239: 03: --> QUIT

    Mají 10 MX záznamů, všechny servery se chovají stejně debilně.

    P.S. Za třeskutě "vtipné" hlášky zdravím nejmenovaného programátora. Dej si ránu, ajnštajne.

  • 23. 4. 2015 11:42

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    M$ "cloud" se prozmenu pri dorucovani choval tak, ze behem cca 10s zkusil asi 100 pokusu z minimalne 10ti Ipcek, coz ho hodilo na blacklist samo o sobe, a pak uz to nezkusil vubec. Mno neni nad to provozovat firemni mailu v coudu, ze ....

    Po par tydnech to nejak prekopali, asi po tom, co na ne par mega ovecek rvalo, ze se jim vsechny maily vracej jako nedorucitelny ... ;D

  • 23. 4. 2015 13:17

    Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----

    Joo, Office 365 mrkvocloud, to je vynález jak stehno. Mj. ta banda blbů neumí ukončit session, prostě vyblije DATA a a ukončí konexi, hotovo. Na co čekat po QUIT na nějaký 221, to je zbytečný...