Ano, SMTP a POP/IMAP sajou. Chce to novou generaci e-mailu!

16.3.2009 21:32 | Přečteno: 2558× |

Volně navazuji na blogpost Miloslava Ponkráce. Současná podoba elektronické pošty v dnešních podmínkách skutečně nemůže plnit svoji funkci a to kvůli zcela jiným okrajovým podmínkám, než v době vzniku

Ty hlavní odlišné okrajové podmínky jsou:

• Dostupnost serverů blížící se 100 %, oproti častým a dlouhým výpadkům v době vzniku protokolů
• Běžná nutnost 8b dat i metadat
• Zlí hošové prdí na jakákoliv omezení netechnické podstaty, narozdíl od konce 70. let, kdy se stačilo na nespamování prostě domluvit

Z toho pár vlastností, které velmi podporují neduhy jako spam, phishing, zmršené kódování a velkou zátěž linek vzhledem k užitečným přeneseným datům:

• Mail se posílá z klienta odesilatele přímo serveru příjemce
• Odesilatel si může do hlaviček From napsat co chce, aniž by o tom server uvedený v těchto hlavičkách věděl
• 8b data především v hlavičkách jsou náchylná na poškození

V tomto světle mi připadají tvrzení stylu email prostě není vhodný na posílání velkých příloh nebo email nezaručuje doručení zprávy příjemci nebo třeba adresa v hlavičce emailu nemusí patřit skutečnému odesilateli jako obhajování neobhajitelného - principiálních chyb návrhu vzhledem k spučasným potřebám. Podle mě je nejvyšší čas navrhnout a uvést do praxe nové protokoly pro elektronickou poštu, které by odpovídaly dnešním potřebám a starostem. Měly by se podle mě držet těchto zásad:

1. Definice kódování - vyžadování UTF-8 v hlavičkách a povinná definice kódování pro každou část dat
2. Oddělit protokoly pro komunikaci klientů se servery (dále c2s) a serverů mezi sebou (dále s2s)

3. Model komunikace klient odesilatele → server odesilatele → server příjemce a/nebo klient odesilatele → oznámení serveru odesilatele, že něco pošlu serveru příjemce → ověření klienta odesilatele serverem příjemce podle jednorázového žetonu → přenos zprávy na server příjemce → klient příjemce

   To kvůli tomu, aby nikdo nemohl poslat email ze svého počítače tvářící se jako kdyby ho odeslala nějaká banka, jejímuž klientovi se chtěl podívat na účet nebo jménem Franty Vomáčky posílat Pepovi Opičkovi doporučení, v kterém e-shopu je zrovna nejlevnější \/!49®4. První model je vhodný v případě, že chce odesilatel ukládat kopie odeslaných zpráv na serveru, druhý pokud to nechce.

   Oba modely komunikace umožňují kontrolu doručení zprávy, protože oba servery vědí o procesu odesílání zprávy

4. Zpětná kompatibilita nového c2s protokolu se zprávami doručenými po (E)SMTP
5. Zpětná kompatibilita - schopnost serveru odesilatele poslat zprávu doručenou novým c2s protokolem serveru adresáta po SMTP - obojí pro plynulý, pro běžné františky uživatele nepostřehnutelný, přechod na novou architekturu
6. Jednotný c2s protokol pro odesílání pošty i její příjem (jak pro offline práci ve stylu POP, tak pro online jako u IMAP). Protokol by měl být navržen tak, aby byl použitelný pro všechny klienty včetně těch s omezenými zdroji nebo pomalým připojení (třeba ty v mobilech trpí na obojí).
7. s2s protokol optimalizovaný pro tuto úlohu. Například možností posílat v rámci jednoho spojení více zpráv oběma směry.
8. Podpora podepisování/šifrování všech částí zprávy nejen pomocí PGP, ale i x.509
9. Standardizace základního značkování zprávy, aby ji mohl uživatel podle svého výběru strukturovat nebo formátovat s definovaným chováním při nepodpoře u klienta příjemce (fallback formátované tělo zprávy → strukturované tělo zprávy → tělo zprávy zobrazené v prostém textu)

Netvrdím, že by tak vymizely úplně problémy s e-maily v současné podobě, ale určitě by se tak vyřešilo několik kulhavých nohou:

• Konfigurace připojení: takto by pro připojení klienta k serveru stačila adresa, heslo (nebo cesta k soukromému klíči, nebo jiný způsob ověření identity) a zaškrtávátko pro zapnutí SSL/TLS
• Automatická kontrola podpory doručení
• Zefektivnění komunikace mezi velkými servery, kde díky penetraci webmailu už stejně funguje komunikace podle prvního schématu o kus výš
• Konec problémů s kódováním: ať už jeho mršení nebo zbytečného natahování zpráv
• Omezení možností pro phishing: když se podvodný email útočící například na klienty ČS nebude moci tvářit jako odeslaný z @csas.cz nebo @servis24.cz, ubere jim to na důvěryhodnosti
• Díky oddělení s2s a c2s protokolů možnost odeslat si zprávu i ze subnetu, který je na blacklistu kvůli spamům.

Bohužel by taková architektura neřešila rozesílání spamů zavirovaným otlakem nebo nedostupnost serveru ze subnetu na blacklistu. Ale i tak mi přínosy něčeho podobného připadají jako smysluplnější než neustálé opakování výše uvedených tezí...

---

PS: ve využívání HTML značek li, ol a ul tentokrát překonávám i seznamového krále Luka.

       

Komentáře

[Ondrej]

a bude to znamenat, ze kazdej mail musi existovat....coz jednak zlikiduje moznost noreply adres a jednak, a to je horsi, moznost domenovejch kosu.

[David Jaša]

Jak to? Mail na noreply adresu může cílový server odmítnout (případně by mohla existovat hlavička ve stylu NoReply: true, aby to klienti poznali ještě před pokusem o odeslání odpovědi) a omezení cílové adresy z toho návrhu nijak nevyplývá, nebo snad jo?

[Luk]

Doménové koše postrádat nebudu - beztak jsou to prakticky jen lapače spamu. Noreply adresy budou moci existovat, prostě to bude adresa, která povede do černé díry.

[Luk]

Tedy tohle mě fakt dostalo:

ve využívání HTML značek li, ol a ul tentokrát překonávám i seznamového krále Luka.

Jinak k jednotlivým bodům:

Ad 1 - vyžadovat UTF-8 je zbytečné. Již dnes lze bez problémů definovat znakovou sadu a zakódování hlaviček.

Ad 2 - stačí vyjít z RFC 4409.

Ad 3, 4 a 5 - souvisí s bodem 2.

Ad 6 - proč navrhovat nový protokol? IMAP plně postačuje pro on-line i off-line použití, včetně odesílání (IMAP Message Submission, zatím je jen v draftu; lze ovšem použít také SMTP rozšíření BURL - RFC 4468). Ano, je složitý (hlavně když uvažujeme i rozšíření). Ale na druhou stranu, pokud uděláme jednoduchý protokol, svádí to k tvorbě vzájemně nekompatibilních proprietárních rozšíření. Jde tedy jen o to, podporovat IMAP včetně potřebných rozšíření.

Ad 7 - na to by stačilo mírně rozšířit SMTP.

Ad 8 - kterých všech částí (snad ne i některých hlaviček)?

Ad 9 - tohle lze bez problémů realizovat v rámci MIME.

[David Jaša]

Ad 1: chce to standardizovat natolik, aby s tímto problémy nebyly vůbec. Dnes AFAIK vyžaduje fuknčnost diakritiky konfiguraci na straně serveru i klienta. O to by se měl postarat protokol samotný

Ad 6: možná to nutné není. Otázka je, jestli se ty samé schopnosti + odesílání zpráv, hledání na serveru apod. nedají vyřešit efektivněji. Inspiraci bych hledal v níže zmíněných protokolech Exchange a Lotus Notes nebo třeba v protokolu AJAXového klienta Gmailu

Ad 8: šlo mi o podpis/šifrování per partes, aby se zpráva dala validně přeposílat. Podpis hlaviček From: a Reply-to: by taky nebyl od věci.

Tedy tohle mě fakt dostalo:

Byl jsem zvědavej, co na to řekneš.

[Filip Jirsák]

proč navrhovat nový protokol? IMAP plně postačuje pro on-line i off-line použití

On už IMAP umí štítky nebo vyhledávání na straně serveru?

[CET]

Pokud vim, tak ano, IMAP umi keywords a take hledani na strane serveru.

Zrovna nedavno se o vyhledavani v hlavickach diskutovalo v alpine konferenci. A vlastni keywords jdou v alpine taky definovat. Samozrejme naprosta vetsina mail klientu implementujou pouze zakladni funkce IMAP a zbytek resi ruznyma obezlickama, veril bych tomu, ze to je hlavne kvuli nekompatibilnim IMAP serverum typu Groupwise nebo Exchange - pro takovy ma alpine jeden hezkej prepinac - "loser".

[Jiří (BoodOk) Kadeřávek]

Mrkněte sem

http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol

[VSi]

• Mail se posílá z klienta odesilatele přímo serveru příjemce

Zrovna tohle podle mě většinou neplatí, i když by to bylo možné. Pokud je tedy "klientem" myšlen poštovní klient uživatele, popř. webmail.

Poštovní klient má obvykle jako server pro odesílání pošty nastaven SMTP server poskytovatele připojení nebo SMTP server v místní síti. Výhoda je, že na SMTP server v místní síti se e-mail z klienta přenese velmi rychle. Server se ho pak snaží doručit na cílový server, který může být přetížený, nebo připojený pomalou linkou, nebo třeba dočasně nedostupný - a tohle všechno uživatel nemusí řešit, maximálně se po určité době dozví, že e-mail nešlo doručit, protože... Obdobně to může být se SMTP serverem u ISP, ale dnes už se moc nestává, že by takový server byl rychlejší než jiný "dál" v Internetu.

Komplikace nastane v případě, že chcete odesílat zprávy s různými adresami odesílatele. Protože cílový server hlavičku From nijak neověřuje, můžu e-maily s libovolnou adresou odesílatele posílat přes "nejbližší" / nejrychlejší SMTP server. Tím je samozřejmě umožněno šíření SPAMu.

Tento problém se snaží řešit SPF (Sender Policy Framework), pomocí kterého můžu určit, které servery mají právo posílat e-maily s adresou odesílatele z mojí domény. Používá to třeba i Google nebo Seznam. Proto když budete posílat zprávy, kde From bude z domény google.com, přes jiné servery než ty od Googlu, pak cílové servery používající SPF takové zprávy odmítnou.

 

Jinak nastíněné nápady jsou celkem dobré. Nevěřím ale, že se tím ještě nikdo takhle nezabýval - vymyslet něco kompatibilního a přijatelného pro všechny nebude jednoduché. Kombinace SMTP + IMAP pro připojení klientů sice funguje docela dobře, ale pokud třeba chci odeslané zprávy ukládat na serveru, přenáší se většinou dvakrát - přes SMTP a pak přes IMAP do odeslaných.

Pak mi taky dost chybí nějaký standardní protokol pro server-side adresář s obousměrnou synchronizací, který by podporoval desktop klient + webmail + mobilní zařízení - něco jako má Exchange. LDAP je použitelný spíš jenom pro čtení.

Zrovna komunikace s klientem ale asi není dnes zásadní problém. Třeba Outlook nebo Lotus Notes mají vlastní protokoly s lepšími vlastnostmi...

[David Jaša]

Mail se sice neodesílá přímo, ale problémy s tím jsou stejné - server odesilatele o tom v principu nic neví a SPF tak, jak je popsané, mi pak přijde jako vytloukání klínu klínem: v sítích, kde je odchozí SMTP z klientských počítačů zakázané, je člověk odkázaný na webmail. Nutnost konfigurace na notebooku pro každou síť zvlášť je taky osina v zadku...

Pak mi taky dost chybí nějaký standardní protokol pro server-side adresář s obousměrnou synchronizací, který by podporoval desktop klient + webmail + mobilní zařízení - něco jako má Exchange. LDAP je použitelný spíš jenom pro čtení.

Jo, i tohle jsem chtěl ošetřit tím c2s protokolem.

[Martin Mareš]

SPF je nápad dost pochybný, který mimo jiné naprosto rozbíjí forwardování pošty. Pozornosti doporučuji spíš DKIM (DomainKeys Identified Mail), který se narozdíl od SPF i stal internetovým standardem.

[alkoholik]

SPF je nahodou napad vyborny. Forwardovani posty funguje, pokud servery korektne prepisuji hlavicky jako treba gmail.
Na zkousku doporucuju rozjet si ho lokalne (SPF zaznamy pro vlastni domenu jenom na LANce) a filtrovat nevalidni SPF procmailem do extra slozky. Me to likviduje o 80% spamu vic. Hlavne ten, ktery me podstrkuje jako odesilatele, protoze nasi vlastni domenu mam samozrejme ve white listu.

[Martin Mareš]

SForwardovani posty funguje, pokud servery korektne prepisuji hlavicky jako treba gmail.

Chcete říci že funguje, pokud se někdo při forwardování chová jinak, než jak to předepisuje standard?

Jak se chová forwardování (respektive relayování, z pohledu SMTP je to naprosto totéž), jednoznačně předepisuje příslušné RFC a prakticky všechny MTA to tak od úsvitu věků dělají. Najednou někdo přijde se SPF a řekne, že aby maily se SPF fungovali, musejí všichni na světě začít forwardovat jinak. Je to chyba ve všech MTA, nebo v SPF?

[alkoholik]

A co si to treba najit sam? http://old.openspf.org/faq.html#forwarding

[Martin Mareš]

Ano, tam píší "forwarding nechodí, musíte používat remailing". Což je s prominutím blbost, chování všech MTA na světě jen tak nepředěláte.

[alkoholik]

Ano, spolu s tim, ze pro 4 hlavni mail daemony pripravuji patche. A je tam odkaz na diskuzi z roku 2004!
Jak uz jsem psal vyse, zkuste si to nasadit pomoci internich DNS a uvidite sam. Seda je teorie, zeleny strom zivota.

[Martin Mareš]

Proč bych se měl snažit vnucovat lidem, aby forwardovali poštu úplně jinak, než je už minimálně 20 let standardem, když mohu místo prohnilého SPF použít DKIM, který je daleko lépe navržený a problémy s forwardováním nemá?

[alkoholik]

Pred 20 lety byly mail servery open relay a kde jsme dnes?
OK, mas ukol: par uzivatelu chce odesilat mailu z domu. Nasazeno mas a) SPF, b) DKIM. Co se stane?
a) Domaci IP uzivatelu pridas do DNS zaznamu a mas hotovo.
b) Uzivatel dostane klic, aby si mohl kazdy mail sam podepsat. Takze mu musis vnutit mail klient, ktery umi pomoci DKIM podepisovat. Uzivateli bude pekne online klic ukraden a objevi se tuny podepsaneho spamu z vasi domeny. Predem upozornuju, ze cerv pro wokna se tuhle dostal mimo jine az do izolovane site fr. letectva, takze tohle povazuju za nevyhnutelne.
Ktery navrh, ze ti prijde lepsi?
A vubec ted neresim, ze je nutne u DKIM mail NEJAK podepsat. Kvalitu certifikacnich autorit u DKIM nikdo nijak neresi! Takze spameri si jich nakonec vygeneruji tisice.

[Luk]

Predem upozornuju, ze cerv pro wokna se tuhle dostal mimo jine az do izolovane site fr. letectva

Kdysi červ řádil také v českém NBÚ a ve VZP (jednalo se o červa z rodu BadTrans, který mj. snímal znaky z klávesnice a odesílal je neznámo kam).

[Deleted [8409]]

Zajímavá úvaha, chybička "vzhledem k spučasným potřebám"

[Let_Me_Be]

Jedine co chybi dnesnimu emailu je funkcni system potvrzeni doruceni + nutnost pouziti elektronickeho podpisu (bud na strane klienta, nebo pokud klient odesle nepodepsany email tak na strane serveru).

[rane]

Zaujímavý blogpost na podobnú tému: http://adam.blog.heroku.com/past/2009/3/16/push_systems_vs_pull_systems/

[xkucf03]

Článek sice zajímavý, ale dost jednostranný – systémy založené na událostech jsou mnohem efektivnější, prostě čekáš, až se něco stane, do té doby nic neděláš, neplýtváš zdroje, a když se to stane, víš o tom okamžitě. Zatímco u pull systémů musíš periodicky kontrolovat „jestli se náhodou něco neudálo“. Stahuješ si klidně desítky RSS kanálů každou půlhodinu, i když se novinky na blozích tvých kamarádů objevují jen jednou za pár dní. A přesto, když se tam nějaká novinka objeví, dozvíš se o tom v průměru se čtvrthodinovým zpožděním. Další problém je, když s tebou chce navázat kontakt někdo nový – je potřeba se předem dohodnout, předem povolit přístup* – zatímco u e-mailu nebo telefonu stačí dát svůj kontakt na web a může mi napsat kdokoli (e-mail tam dám v podobě nečitelné robotům).

Ideálem je kombinace obou způsobů – systém založený na událostech s efektivním filtrováním vyžádaných/nevyžádaných (oprávněných/neoprávněných) požadavků.

 

*) což je namístě třeba u těch peněžních převodů (kteditky jsou fuj).

[pht]

Není to náhodou popis XMPP?

[Zdenek]

TAky mi to tak prislo

[David Jaša]

Ano, inspicaci XMMP můj návrh nezapře.

[Käyttäjä 11133]

Ještě že nechceš zprávy posílat jako XML (nebo snad chceš? )... To bych si toho s telnetem pak už moc neposlal.

[xkucf03]

njn, taky si takhle rád hraji (i přes pop3 se dá číst pošta telnetem), ale možnost manuálního odesílání telnetem není smysl těchto protokolů, je to jen vedlejší efekt → návrh nového systému by se mu neměl podřizovat. O tom, jak nahradit SMTP protokolem založeným na XML jsem tu už v nějaké diskusi polemizoval Tehdy mi z toho vyšlo, že by to bylo moc hezké, ale taky moc práce a malý přínos (ale v rámci nějakého nového řešení e-mailové otázky to vidím jako celkem jasnou věc).

[Martin Mareš]

Zajímavý návrh. Ale jak konkrétně pomůže proti spamu a phishingu?

[CET]

Tak ted uz z toho jenom udelat standard a pak donutit vsechny firmy produkujici bastl SMTP servery (Microsoft, Novell), aby se toho standardu striktne drzely. Osobne pochybuju, ze se ti to povede, kdyz nejsou schopny dodrzovat ani stavajici jednoduchy standardy.

Osobne vidim reseni v pouzivani GPG nebo X509 overenych certifikatu a odmitani nepodepsanych emailu. Podepisovani a sifrovani pomoci GPG nebo X509 podporujou dneska uz snad vsechny klientske programy, takze je akorat problem v tom, ze lidi jsou liny. Kdyz by doslo k masovemu rozsireni certifikatu pripadne GPG, mohla by jit i cena dost dolu.

Pak by nebyl problem pripadneho rozesilatele spamu s podpisem lehce dopatrat a potrestat a nepodepsane emaily nebo s podpisem od neuverene autority se muzou rovnou zahazovat.

[David Jaša]

Podepisovani a sifrovani pomoci GPG nebo X509 podporujou dneska uz snad vsechny klientske programy, ...

Vzhledem k množství programů určitě. Nezapomínej ale na webmaily, které takové věci nepodporují a nepoužívá je zrovna malá část uživatelů...

[Vašek Lorenc]

To jako svěřit provozovateli webmailu svůj privátní klíč? To asi není tak docela rozumný návrh..

[Martin Mareš]

Nedávalo by smysl, aby provozovatel webmailu alespoň podepisoval všechny odchozí maily nějakým klíčem společným pro všechny uživatele?

[Filip Jirsák]

Ono by vůbec dávalo smysl, aby odchozí e-maily podepisoval (pro účely doručování) odchozí server (společným klíčem). Blokovat každého Pepu z Horní Dolní někde v Číně se zavirovaným počítačem asi nebude efektivní boj proti spamu. Pokud by si to pod pohrůžkou blokování všech e-mailů musel pohlídat jeho správce, bylo by to něco jiného.

[Martin Mareš]

Přesně tohle (ale jen pro hlavičky, ne pro obsah), dělá právě DKIM.

[Käyttäjä 11133]

No on hlavně není problém to implementovat jako rozšíření do prohlížeče, pro firefox dokonce už podepisující plug-in existuje.

[YYY]

Nemyslim, ze bude kdy vule implementovat nejaky novy standard. Sice je pravda, ze soucasna situace je smutna, ale na druhou stranu by prechod na novou architekturu znamenal takove naklady, ktere nikdo nebude chtit vynalozit.

[JS]

V SMTP se nevyznam, ale pripada mi, pokud uz delat nejake radikalni zmeny do emailu, tak ve stylu:

http://video.google.com/videoplay?docid=-6972678839686672840

 

[Yokotashi]

Chybi v tom jedna podstatna vec - nezdrazuje to spam.

Co kdyby - kdyz nekdo chce poslat mail - dostal od pocitace prijemce ulohu k vyreseni. Treba faktorizaci cisla. Na whitelist by se posilalo cislo "6", ktere se faktorizuje jednoduse, na ne-nebezpecne domeny neco, co se faktorizuje tak desetinu sekundy a na rizikove domeny, treba 10 sekund.

Nebo jeste lepe - na nezname domeny 0.1 sec a na domeny, ze kterych uz prisel spam treba minutu.

Samozrejme vy slo spammovat dal ... ale najednou by kazdy spam stal nejaky procesorovy cas a masivni spammovani by znamenalo nakup HW. Navic by si kazdy uzivatel mohl zcela individualne zvolit, jak velka cisla bude jeho stroj posilat. Na druhou stranu by to neznemoznilo komunikaci protoze je stale lepsi faktorizovat neco na slabem pocitaci ctvrt hodiny (a pak uz byt ve whitelistu), nez poslat mail a nevedet, zda dosel dokud prijemce neodpovi.

[M. Lox]

Spousta spamu pochází ze zombií, takže spammeři mají volného hardwaru a výpočetního výkonu hromadu.

[Luk]

To už ale není primárně o poště, nýbrž o zabezpečení jednotlivých počítačů (a celých lokálních sítí) proti malwaru. Tedy jednak uživatelská kázeň, a samozřejmě také eliminace bezpečnostních děr v aplikacích.

[M. Lox]

To máš jistě pravdu, ale nesouvisí to s tím, že zatěžování odesilatelů pošty proti spamu nikoho neochrání, jenom to přidělá spoustu práce administrátorům serverů „počestných“ a navíc idea stoprocentního zabezpečení všech počítačů je sice krásná, ale naprosto nereálná. Většina lidí se o bezpečnost svého počítače vůbec nezajímá a stejně nejdou vychytat všechny chyby, které se v softwaru mohou vyskytnout.

[Luk]

To máš jistě pravdu, ale nesouvisí to s tím, že zatěžování odesilatelů pošty proti spamu nikoho neochrání, jenom to přidělá spoustu práce administrátorům serverů „počestných“

Také to nevidím jako řešení, reagoval jsem obecně na problematiku zombie.

idea stoprocentního zabezpečení všech počítačů je sice krásná, ale naprosto nereálná

Nereálná je, ale to neznamená, že bychom se neměli snažit o to, aby počítače nebyly aspoň rozumně bezpečné. Tím mám na mysli, aby například software nemusel vyžadovat zbytečná oprávnění, aby se používaly firewally a antiviry (když už se to nedá řešit čistěji) nebo aby (na pracovních strojích) uživatelé neměli možnost instalovat software, jaký se jim zlíbí.

Většina lidí se o bezpečnost svého počítače vůbec nezajímá

Ale zajímá - v okamžiku, kdy přijdou o data nebo jim někdo vytuneluje účet