Na poslání mailu dneska potřebuju spf, dkim, dmarc, ptr, nebýt na spamlistu, nebýt na nějakým rating serveru typu return-path blbě hodnocenej, používat šifrování, aby gmail neukazoval červenej zámeček a teďka ještě webserver a další bordel do dns. Přitom ani tohle všechno mi nezaručí, že mail doručím.
Příklad z poslední doby:
vlastním celý IP prefix /22 nově přidělený od RIPE. Chci poslat mail na domény hostující u MS z některé z IPček. Mail není doručen, 550 IP banned. Celý rozsah se nenachází nikde na žádném blacklistu. Mail odpovídá požadavkům na spf, dkim. Řeším s indickou podporou 14 dní problém, kdy mi 2x oznámí, že už to jde a přesto to nejde. Nakonec včera již oznámili, že to půjde, opravdu to jde, ale maily končí v Junkfolderu. Po shlédnutí hlaviček a odfiltrování 90% sraček, který tam přidává MS exchange zjišťuju, že DKIM FAIL. Opakuji test a posílám tu samou zprávu na MS i gmail. U MS opět fail, u gmailu hlási DKIM PASS. Dočítám se, že MS často rozjebe mail tak, že dkim jde do prčic. Poslal jsem to opět do indie, ať si mají s čím hrát.
Nakonec jsem jen tak na test poslal mail z mojí soukromé domény a úplně jiné IP patřící mému housingu. IP mám od nich několit let, spam neposílám, maily většinou přijímám a odesílám jen málo. Přesto po odeslání mailu na MS končím také v Junku.
Jinak samozřejmě ani jedno z těchto opatření mě neochrání před spamem. Ten dostávám celkem pravidelně, projde to mailscannerem i rspamd. Samozřejmě spamy mají v pořádku spf i dkim.
Řešit maily je boj s větrnými mlýny, nedivím se, že lidi prostě hostujou u MS nebo G, kdo by se s tím chtěl crcat. Na druhou stranu, asi těch mailů moc nedostanou.
On i gmail má máslo na hlavě. Jejich selectory mají chybnou syntaxi, nicméně z nějakého důvodu to stejně nikomu nevadí a dkim test bude pass.
Příklad:
host -t txt 20161025._domainkey.gmail.com
20161025._domainkey.gmail.com descriptive text "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqR" "tqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB"
GMail dlhodobo zhorsuje moznost forwardovat nan maily.
Po prestudovani https://serverfault.com/a/375465/24187 sa klient rozhodol ze bude hostovat u G.
Ono je za tym skvela (aj ked vydieracska) obchodna politika: pri forwarde mailu na strane google SMTP servera odpovedat RECEIVED a na strane gmailu ten mail pre non-g-suite domenu sprosto zahodit (ani nie do spamu, proste hodit na zem a nedorucit). Tym cloveka v podstate donutia prestat pouzivat cielove gmail konto kam sa tie maily forwarduju a alebo si zaplatit tych 5€/user/mesiac za najmensi g suite.
Vacsina ludi je spokojnych s gmailom takze zaplati.
Je tam este moznost nerobit forward ale POP3 pull, ale gmail stale pritvrdzuje podmienky pre nastavenie POP3 servera s ktorym sa bude bavit takze to vidim len ako odlozenie nutnosti prejst na G suite.
Asi sa to da aj inak, ale s malymi klientami sa s tym nikomu nechce hrat.
Jak sem byl spocatku nadsenej, tak ke konci prislo vystrizliveni. Spoustet https-servr kvuli kazde domene pro kterou sbiram postu je mirne receno neprakticke.
Proc tech par zaznamu z mta-sts.txt radsi nedat rovnou do dns? Kazdou (mail) domenu nekde obhospodaruje nakej dn-server (kam stejne jiz musim pridat zaznam pro mta-sts.domena.tld), jenze ne pro kazdou mail-domenu musi nutne jiz bezet web-servr...
Aha, takže pokud jde o bezpečnost, tak se budeme řídit tím šlompem, co na to nejvíc se*e? No to je hezký...
DNSSEC je základ. A doména snad má správce.V případě DNSSEC by mělo být postupováno takhle:
1) Důrazný upozornění správce domény, že DNSSEC bude povinný a bez toho se jejich zákazníkům plno věcí rozbije.
2) Pokud se to do měsíce nezmění, pustit info novinářům v dané zemi, že se "rozbije internet" vlivem jejich registrátora.
3) Za měsíc po tom DNSSEC prostě v infrastruktuře vynutit. V ten okamžik rázem to DNSSEC bude.
Problemem a "dirou" v MTA-STS je stale ta zavislost na DNS. I dotaz na samotnou existenci politiky muze byt pozmenen ci zcela potlacen. Stejne jako muze byt potlacene STARTTLS u SMTP relace (coz mimochodem delaji i nektere firewally, aby mohly provadet dalsi inspekci) - i kvuli cemuz se MTA-STS vymysli. Ze je samotna politika transportovana na HTTPS je irelevantni. V extremnim pripade by slo ziskat i DV certifikat pro zmineny policy server, ktery je vzdu ve tvaru mta-sts.[domena] (samozrejme, ze to je slozitejsi a narocnejsi, ale nikoliv nemozne a nepredstavitelne). Bezpecnost je o nejakem retezu a pokud je slaby jeho prvni clanek (a tim DNS bez DNSSEC bezpochyb je), tak bytelny zbytek okolo to uz nezachrani.
Podstata problemu se vubec neresi a to bych videl jako zakladni selhani - i tech "velkych", co MTA-STS standard predlozili a kterym se do DNSSEC nechce (Google, Microsoft...). Oportunisticke sifrovani na komunikaci mezi MTA stale preziva a vymysli se vselimozne obezlicky kolem. Nabizi se otazka, proc se oportunistickeho sifrovani proste nesnazi zbavit. I u DNS jsme se uz dockali standardu, ktery na jinem portu ma TLS mandatorni, HTTP(s) tu mame uz sakra dlouho, Telnet nam taky vystridalo SSH... ale u SMTP v pripade MTA-to-MTA komunikace porad nic. Samozrejme, ze ta zmena nebude hned - ale nekdy se zacit prece musi. Proc delat veci jednoduse - kdyz to jde slozite.
Napadnutelne to je samozrejme i pozdeji. Do DNS staci indikovat zmenu politiky a do cesty vhodne nastrcit webovy server dle scenare viz vyse - ktery podvrhne i zbytek, tedy i celou jinou politiku. Jisteze to je uz hodne komplikovane a narocne na realizaci, ale nikoliv uplne nemozne. Proste takova bezpecnost "napul".
Moznosti je.... DV certifikat nebo treba natlak govermentu na nejakou CA - bez ohledu na CT (ktere pomuze spise s post-mortem analyzou)... aneb jedna vec je ta data nekde verejne "mit", druha realne - a v realnem case - kontrolovat, ze nejaka CA "nahodou" vystavi certifikat, co by nemela... takove incidenty tu uz ostatne i byly, to nejsou zadne teorie :-)
Samozrejme, pokud mam implementovane DANE (na domene s DNSSEC) a otisk aktualne pouziteho certifikatu v TLSA zaznamu, tak si rovnou muzu overit, ze komunikuji se spravnym serverem a ne nejakym podstrcenym nekym na puli cesty. V realu je cely DNSSEC "chain-of-trust" vic pod drobnohledem a obecne hlidatelne jednoduseji, nez chovani jednotlivych certifikacnich autorit - kde problematicnost kontroly praxe opakovane dokazala.