Vlákno názorů k článku Gmail označuje nešifrovanou poštu. Jak to opravit? od kutr - Google se pořád snaží vytvořit dojem, že šifrování...

Slovo "privacy" v té odpovědi nemá co dělat. Dále zapomněli říct, že si je může přečíst každý server na cestě i bez virů, takže vlastně oproti nešifrovanému přenosu vůbec žádná změna.

Nemyslím si, že by v odpovědi slovo „privacy“ být nemělo. A ten „každý server na cestě“ jsou ve skutečnosti jen servery domény odesílatele a servery domény příjemce. To je dost výrazné zlepšení ochrany soukromí. Ano, předpokládá se zde, odesílatel důveřuje tomu, jehož prostřednictvím odesílá poštu a příjemce stejně tak důvěřuje tomu, jehož prostřednictvím poštu přijímá.

Jestli to opravdu není žádná změna, tak vám pošlu PCAP dump jednoho e-mailu přeneseného s TLS a klidně vám vyplatím odměnu, když mi napíšete, co bylo jeho obsahem.

To by mě zajímalo jak to zaručíte?

Je to zaručené přímo v SMTP protokolu. MTA odesílatele se zeptá na MX záznam domény příjemce a poštu předá tam. Systém je samozřejmě postaven na tom, že uživatel, který je původcem zprávy, má důvěru k prostředníkovi, kterému zprávu předává k doručení a stejně tak příjemce má důvěru k případnému prostředníkovi, který jeho schránku hostuje. Ostatně, oba mají na výběr, jakého prostředníka zvolit či případně se obejít bez něj.

Žádná náhodná třetí strana či skupina dalších serverů, přes které pošta prochází se v přenosu pošty nevyskytuje a nikdy se nevyskytovala.

Router není poštovní server. Když dva poštovní servery mezi sebou posílají e-mail šifrovaně, routery po cestě se k obsahu nedostanou. Právě proto se komunikace mezi mail servery šifruje.

server třetí strany != router třetí strany

Ano, e-mail nikdy neprochází přes router třetí strany – neprochází totiž přes žádný router. E-mail je záležitost aplikační vrstvy, kdežto router je zařízení síťové vrstvy, takže ničemu jako e-mail vůbec nerozumí, vidí jen spoustu datagramů. Routery pro e-maily se jmenují MTA a běžně se jim říká poštovní servery. Pro ně platí, co jsem psal dříve, tedy že se na přenosu podílejí jen ty, které zvolil buď odesílatel, nebo adresát.

Proti pasivnímu odposlechu na routeru třetí strany TLS zabezpečení přenosu pomáhá, při přidání autentizace pak dokonce pomáhá i proti aktivnímu/MitM odposlechu.

Předně tvrzení, že se k mailu třetí strana nemůže dostat, v uvedené citaci není.

Navíc je potřeba brát kontext, na který citace reagovala, totiž že:
Dále zapomněli říct, že si je může přečíst každý server na cestě i bez virů, takže vlastně oproti nešifrovanému přenosu vůbec žádná změna..

Moje věta o nepřítomnosti náhodných třetích stran či skupiny serverů se tedy vůbec nevztahuje k možnosti odposlechu/mo­difikace zprávy během přenosu, ale k množství serverů, na kterých je možné zprávy odposlouchávat a modifikovat i pří TLS zabezpečení přenosu.

ne, MX vubec pouzivat nemusi, muze mail predat naprosto libovolnemu dalsimu mailserveru, vse v zavislosti na konfiguraci…
Jistě, proto má také odesílatel možnost svobodně zvolit takový server, kterému důveřuje, že s poštou dělá jen to, na čem se dohodli.

Co vic, dokonce se predpoklada, ze odesilatel bude pouzivat geograficky nejblizsi MTA.
Zdroj?

japa asi tak uzivatel zjisti, jak je MTA nakonfigurovanej? Zeby presne nijak?
A co na tom záleží? Uživatel musí předat poštu prostředníkovi, kterému důvěřuje, nebo si ji doručit sám. Stejně jako když v reálném světě posílá zprávu po poslovi, musí vybrat důveryhodného posla, nebo ji donést osobně na místo určení.

To, ze se maily primo predavaj je zcela BEZNA konfigurace. Naprosto bezne existuje sada stroju ktery maily prijimaj, a pak jina sada stroju, ktery maily odesilaj, mezi nima pak muze jeste byt dalsi sada stroju, ktery (treba) provadeji nejakou analyzu (spam, viry, ...)... ze by vse delal jedinej stroj je spis vyjimecny.
To není v rozporu s ničím, co jsem dříve napsal.

A japa maily putujou mezi nima? No to vi buh. A myslis ze to bude v hlavickach? Vubec byt nemusi.
Vždycky je to ale v rukách buď osoby, které důvěřuje odesílatel, nebo osoby, které důvěřuje příjemce. Nikdy nejde o náhodnou třetí stranu.

Proc ma DHCP jako jeden z parametru mailserver? Asi proto, aby ho uzivatel nepouzil ... jinak si najdi prislusna RFC.
Kdo tvrdí, ten prokazuje. Která jsou ta příslušná RFC? RFC 2132 specifikuje DHCP volbu pro mailserver, ale žádným způsobem nepředepisuje, jak by se tato volba měla používat. Dokonce jsem ani nenašel informaci o tom, že by existovala nějaká implementace MUA, která by tuto DHCP volbu používala.

Nehlede na to, ze uzivatel velmi casto navyber vubec nema, protoze nekteri "takyisp" mu jinej nez svuj MTA neumoznej kontaktovat.
Obvykle bývá pouze zablokovaný provoz na cílový port 25. Porty 465 a 587, které se pro předávání pošty k odeslání používají, blokovány obvykle nejsou.

muze mail predat naprosto libovolnemu dalsimu mailserveru
Přičemž ten naprosto libovolný další mailserver ten e-mail odmítne s tím, že ten e-mail není určen pro něj a nebude dělat open relay. A pokud náhodou nějakou open relay najdete, nebude od ní zase přijímat e-maily nikdo jiný, protože bude na všech blacklistech.

Co vic, dokonce se predpoklada, ze odesilatel bude pouzivat geograficky nejblizsi MTA.
To se předpokládalo kdysi dávno. Dnes už nikdo nic takového nepředpokládá, třeba SPF s tím nebude fungovat vůbec a DKIM by mnoho příjemců asi překvapilo.

Tzn NEEXISTUJE ani jediny duvod, proc by nekdo mel necemu takovymu prikladat naprosto jakoukouli duveryhodnost, proste proto, ze nic NEZARUCUJE, ze ten mail nebude putovat siti vi buh kudy a vi buh kam.
To jste ale ale obrátil to tvrzení naruby. Google neoznačuje poštu, která přišla šifrovaným kanálem, právě naopak, označuje poštu, která přišla nešifrovaným.