Názory k článku Postfix: generování zpráv o nedoručení jen pro určité cílové domény
-
Ja z toho mam pocit, ze gmail a spol, kteri maji na hratky s postou cele tymy lidi a dostatek vykonu si pomalu ale jiste buduji vlastni mailovy standard. Neuplyne pul rok, aby clovek nemusel kvuli gmailu vymyslet dalsi a dalsi opicarny.
Samozrejme boj proti spamu je spravna vec, ale ja nejsem zdrojem toho spamu, dokud google neodpovida, ze maily pro legitimni uzivatele nechce, protoze se mu nelibi.
Presne z toho duvodu zde popisovaneho jsem ted zvazoval nasazeni postscreenu, abych zase delal to same co googl, tedy odmital postu uz na prijmu. Jenze.. nikde jsem se nedocetl, zda to opravdu funguje.
-
Ja z toho mam pocit, ze gmail a spol, kteri maji na hratky s postou cele tymy lidi a dostatek vykonu si pomalu ale jiste buduji vlastni mailovy standard.
Ono to tak v podstatě je. Nikdo se nedokázal shodnout na práci na nástupci skoro 40 let starého SMTP standardu. Takže nezbývá, než ho inovovat.
Google je mistr v "soft" prosazování. Umí bravurně využívat svoji technologickou a obchodní sílu. Dává svá díla k dispozici veřejně a každý má "možnost" technologii implementovat. Malí hráči na to ale, přesně jak píšete, nemají prostředky (a čas). Koncový zákazník, spotřebitel, nevyhnutelně dojde k tomu, že je lepší si zvolit velkého partnera. A v tomto bodě Google získává.
Dále ze zkušenosti víme, že Google je otevřený do chvíle, dokud bojuje o určitou oblast. Jakmile ji vybojuje, začne kosit silou (např. jeho politika Androidu, kdy na začátku podporoval každého výrobce, dnes už ty slabé odřezává). V tom si Google nezadá s Microsoftem a ostatními.
Obávám se však, že to nemá řešení. Na Gmailu má svoji poštu podstatná část světa a není jiná možnost než zůstat kompatibilní s Googlem. Vy potřebujete je, oni Vás ne. Jen to nikdy neřeknou, ani nenaznačí, prostě jen pokračují po svém.
-
Vzdycky bude vzdycky nejake sede pasmo, kdy jedno antispam reseni to jeste pusti a druhe nepusti, takze nadeje, ze dokazu na prijmu nabrat jen emaily, ktere zarucene pujdou dal preposlat je minimalni.
Nemyslim, ze je mozne dosahnout stejneho chovani na lokalnim mailserveru jako na cloudu. Proste ta velikost jim hraje do karet, kde my cvicime bayese na sta tisich emailu oni to delaji na miliardach. Kdysi se to dalo resit pres https://en.wikipedia.org/wiki/Postini ale to Google koupil a zabil, resp. neni to mozne koupit samostatne.
Dneska se da koupit https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/exchange-online-protection-overview?view=o365-worldwide, to jsem s postfixem zprovoznil a na testovacich domenach to chodi, ale nakonec zadny zakaznik nemel zajem o ostre nasazeni. Tam je samozrejme problem, ze kdo chce mit dorucovani posty pod kontrolou, tak nenastavi MX zaznamy nekam do cloudu. Kdyby byl zajem clanek o tom napsat muzu, ale je to cele jednoducha klikacka.
Ale i kdyz se budou emaily preposilat mezi O365 a Googlem (a obracene), tak budou nejake co neprojdou.
-
J ouda (neregistrovaný)
To že nedojdou bych jim celkem odpustil, to je možná nechtěný, ale celkem i předpokládaný stav, ale co konkrétně Googlu odpustit nedokážu je to, že za určitých okolností zprávu přijme, a prostě smaže.
Pochopil bych reject už během SMTP session, pochopil bych následné NDRko, stejně jako doručení do spam folderu a/nebo v nejhorším případě vygenerování zprávy adresátovi že od x.y bylo z zpráv zahozeno.Ale tohle je jednoznačně prasárna (a pak se člověk diví, když zákazník reklamuje že nedostal fakturu, a v logu je samozřejmě "delivered")
-
Toto je ale princip, který mail servery při boji se spamem využívají dlouhé roky. Existuje pásmo, kdy jste o mailu přesvědčený, že je závadný (zavirovaný, vysoké spam score, phishing, ...), takže nechcete s ním zákazníka (příjemce) otravovat. NDR v takovém případě generuje zbytečný traffic a poskytuje odesilateli-botovi informace, na základě kterých může obsah dál "ladit", aby příště prošel.
E-mail není nijak garantovaný, že dojde, existuje mnoho stavů, kdy může zmizet a nikomu se nedostane informace. To je dáno protokolem. Na e-mail nejde v žádném ohledu spoléhat - ostatně i proto máme datové schránky, kde je doručení garantováno.
-
Filip JirsákStříbrný podporovatelE-mail není nijak garantovaný, že dojde, existuje mnoho stavů, kdy může zmizet a nikomu se nedostane informace. To je dáno protokolem. Na e-mail nejde v žádném ohledu spoléhat
To je pohled ajťáka naprosto odtrženého od reality. Lidé samozřejmě spoléhají na to, že e-mail dojde.ostatně i proto máme datové schránky, kde je doručení garantováno
Není. Zpráva může být zablokována např. antivirovou kontrolou. -
To je pohled ajťáka naprosto odtrženého od reality. Lidé samozřejmě spoléhají na to, že e-mail dojde.
To je sice hezké a pravda, ale SMTP to prostě nenabízí.To je prostě state of art a ajťáci se můžou klidně rozkrájet, ale jakmile zpráva opustí MTA, který mají pod kontrolou, už nikdy nezjistí, jestli byla doručena. Dál můžeme vést diskuse o tom, co znamená doručena. Jestli doručením myslíme převzetí na straně MDA, nebo jestli uložení do mailboxu, nebo jestli stažení do MUA...? Protože v každém kroku od MDA do MUA může dojít k chybě / zahození. Dokonce až za MUA, v rámci OS může dojít ke ztrátě (např. zmiňovaný antivir).
Uživatel je na to myslím docela přivyklý (ale nemyslím si, že je to dobrý stav). Funguje to obdobně, jako poštovní služby (ty na hmotné zásilky :)). Taky nevíte, jestli byla zásilka doručena. Když podáte zásilku doporučeně, lze s vynaložením úsilí dohledat, jestli byla převzata a kým. Teprve když ji podáte označenou do vlastních rukou a vyžádáte dodejku, můžete začít pracovat s tím, že doručena byla.
Jo, je to jak v devatenáctém století, ale žádné východisko se nerýsuje.
-
J ouda (neregistrovaný)
Můžete být prosím konkrétní, kdy při korektní implementaci podle rfc takový stav (mail zmizí a nikdo se o tom nedoví) může nastat?
Pomiňme aktivní MitM kdy útočník aktivně stripuje STARTTLS v EHLO a falšuje 250 po sekci DATA, a pak samozřejmě události které obvykle končí RMA mailserveru.ad. pásmo - od toho existují 4xx errory, během kterých se dá udělat spousta věcí (třeba počkat až se seběhne víc infa z celého světa a pak se dá rozhodnout jestli to vyhodit přes 5xx, nebo to přijmout a doručit, ostatně to komerční produkty běžně dělají), v obou případech se o tom někdo dozví a dá se to řešit.
-
Můžete být prosím konkrétní, kdy při korektní implementaci podle rfc takový stav (mail zmizí a nikdo se o tom nedoví) může nastat?
To je stejně blbě formulovaná otázka, jako kdybych se Vás ptal, kde je v RFC popsáno, jak rozlišovat legitimní mail od spamu. Ostatně, většina RFC by nikdy nevznikla, kdyby někdo nejdřív nestvořil koncept a první implementaci přes rámec těch předchozích.
-
J ouda (neregistrovaný)
Takže na zcela přesnou technickou otázku zní odpověď (omlouvám se jestli nebudu citovat zcela přesně) "základní normy jsou k ničemu, ať žije Divoký Západ"?
Jinak čistě mezi náma, i rfc5321 ochranu před spamem zmiňuje. Dovolím si citaci, ke které opravdu není co dodat:
"As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice.
However, it is extremely dangerous and violates a long tradition and
community expectations that mail is either delivered or returned. If
silent message-dropping is misused, it could easily undermine
confidence in the reliability of the Internet's mail systems. So
silent dropping of messages should be considered only in those cases
where there is very high confidence that the messages are seriously
fraudulent or otherwise inappropriate." -
Filip JirsákStříbrný podporovatel
Například pokud mail server zapíše e-mail do fronty, potvrdí odesílateli jeho přijetí a pak odejde disk, na kterém ta fronta je. Ono obecně RFC řeší komunikaci mezi zařízeními, skutečné doručení ale závisí na spoustě dalších věcí, které RFC nepokrývá.
ČLÁNKY DO MAILU