Názory k článku
Čeká elektronickou poštu revoluční změna?

Pro pochopení jak vlastně celý NGMP protokol funguje je vhodné ukázat funkci na typickém případě kdy jedna osoba zasílá email osobě druhé pomocí nového protokolu NGMP.
Na Vaší klávesnici nefunguje tlačítko vpravo od písmene M?

Mno, na mám domácím počítači mi běží SMTP a nějaká ta e-mailová konference, není to žádný problém. Tady pořád čtu ISP, ISP -- předpokládám, že lze ISP nahradit slovem kdokoli, jinak je to konec rovnoprávnosti a celkově na houby. A cron mi pak bude posílat zprávy také přes mého ISP? ;-) A navíc se do toho v textu nějak pořád plete IM -- což je doufám jen nějaká představa možných o klientech, výhodou mailu je, že chodí, přeposílá se, třídí procmailem, a na konci si ho třeba i přečtu -- vyskakujících okýnek se děsím...

Instant Messaging má jistě své výhody, ale taky nevýhody. Převedení e-mailu z jeho velmi robustní off-line podstaty na nejistou on-line půdu odstraňuje možná současné problémy se spamem (přičemž nijak nevylučuje, že se objeví nové, šité na míru IM), ale taky odstraňuje všechny stávající výhody e-mailu a SMTP. Hlavní rozdíl (a hlavní nevýhoda) mi totiž přijde v opačné filozofii:

SMTP - Co nejrychlejší distribuce zprávy co nejblíže k adresátovi (až uložení do schránky na jeho mailový server) - typ "přišel vám balík, nechali jsme vám ho v kůlně";

NGMP - Udržování zprávy co nejblíže odesílateli bez jakékoli distribuce - typ "haló, tady pošta, Franta z Plzně vám posílá balík. Leží ve skladu na poště v Plzni, přijeďte/pošlete si pro něj".

NGMP server nesmí být nikdy off-line. Zatímco SMTP můžu běžet na serveru připojeném k Internetu jen příležitostně (pošťáci naloží přijaté balíky na náklaďáky a už se o ně nemusí starat; můžou klidně na víkend zavřít poštu) - tak NGMP musí být permanentně on-line (ve skladu jsou pořád nějaké balíky a kdykoli si pro nějaký může kdokoli přijet). Dále - pokud bude v té Plzni povodeň a Franta pošle narychlo zprávu všem svým známým, nikdo už už si ji nikdy nemusí přečíst; jeho pošta, kde ta zpráva zůstane, je odříznutá od světa. Jinými slovy: tím, že se zprávy nechávají na serveru nejblíž odesílateli a nedoručují se naopak co nejblíže adresátům, je protokol méně robustní a méně otřesuvzdorný. Pokud v době, kdy si adresát kontroluje došlou poštu a rozhodne si stáhnout vybrané maily, zrovna neexistuje (kvalitní) spojení mezi ním a serverem odesílatele (což může být zatraceně "dlouhé" a klikaté spojení), tak si zprávu prostě nestáhne.

Dále - v případě SMTP si můžu svou došlou poštu nechávat na serveru (jednou si ji čtu z kavárny, podruhé z PDA, po měsíci ji dávkově zkopíruju na lokální počítač nebo smažu atd.). V případě NGMP si buďto zprávy musím "stáhnout k sobě" při prvním čtení, nebo nechat zahlcovat servery odesílatelů. Jenže SMTP je "můj" server - o jeho zaplnění, o prostoru na něm atd. si rozhoduju sám (resp. po dohodě se svým ISP). O serverech NGMP nerozhoduju, mám jenom za povinnost "si sakra už vzít ten balík a konečně vypadnout, nevidíte, co je tady lidí?!".

Nějaké masové nasazení NGMP mi nepřipadá jako dobrý nápad - resp. ano, jako doplnění IM komunikace (i když na druhé straně tolik nového oproti stávajícím IM službám nepřináší). Ale IMHO může stát jen jako alternativa nějakého robustnějšího off-line protokolu. Když ne SMTP, tak třeba AMTP, nebo nějaké jiné novější verze. Instant Messaging je jistě fajn věc, ale není všespásný, není univerzální a rozhodně ne pro každého.

A argument o spamu je IMHO taky zcestný. Podstata problému je jinde a jiný protokol ho nemůže vyřešit (dnes se vesele spamuje i na ICQ, na mobilech i v chatech - technologie je vedlejší). Ať se vymyslí sebelepší protokol, vždy se najdou cesty, jak jeho prostřednictvím spamovat - je proto nesmysl vymýšlet protokol primárně jako protispamový.

Hlavní půvab mailu je v off-line komunikaci (jinak už si dávno všichni posíláme zprávy a soubory přes ICQ a AIM). Řešení problému SPAM tak, že se mail nahradí online komunikací, řešením není.

Ještě dodatek - tenhle způsob řešení problému SPAM mi připadá stejný jako "řešení" terorismu v dopravě. Než se cestující dočkají odbavení, lékařských vyšetření, osobních prohlídek, rozborů DNA a dobrozdání psychologů před nastoupením do "rychlého" letadla, má běžný zaoceánský parník půl cesty za sebou ... Tak všichni začnou raději jezdit lodí - do doby, než někdo vyhodí do vzduchu první parník...

pekne napsany prispevek :-)

k clanku bych jen dodal, ze se mi nelibilo umisteni zminky o AMTP az na konci clanku (to melo byt na zacatku!), a take ze si myslim ze nakonec bud zvitezi modifikace SMTP nebo e-mail jako sluzba zanikne (na epidemii spamu).

Já bych viděl hlavní problém v tom, že chybí rozlišení, co je standard Internetu, co je draft - jako třeba AMTP, a co experimentální úvahy.

Hlavní nedostatek plyne z chaosu ohledně stáří protokolu SMTP. Ten je podle RFC821 jeden z nejstarších, ale byl rozšířen na ESMTP - jak se nyní skoro všude přenáší pošta - a teprve relativně nedávno začalo být (podle RFC2821) všechno označováno jen jako SMTP.
Otázka pak zní, je opravdu všechno, o čem se autor zminuje, nezahrnutelné do dalších možností SMTP (nedávno ještě nazývané jako další možnosti ESMTP) ?
Alespon AMTP je jen další rozšíření (E)SMTP o oveřování příjemce, ale s přenosem při šifrovaném spojení. Takže zase až tak moc převratného podle mě AMTP nepřináší.

ja vzdy shledaval za prinejmensim komicke, ze vetsina standardu na webu je vlastne pozadavek k komentari (RFC)..Minimalne mi to rika, ze cela metodologie schvalovani standardu je na draka...

Kdyz uprednostnujete formalismus pred vysledkem ...

Mane si pamatuju, ze sveho pusobeni okolo domen na podzim 1999 nekolik rozhovoru s pravniky, kteri nebyly schopni naprosto pochopit, jak je mozne, ze neco tak rozsahleho a masivne pouzivaneho po celem svete, jako je domenovy system, funguje, aniz existuji formalni mezistatni dohody, pisemne smlouvy mezi spravci DNS na jednotlivych urovnich - a vubec - cely ten formalne-pravni kolotoc, na ktery jsou oni zvykli a mysli si, ze bez nej muze fungovat maximalne vesnicky sachovy spolek - a ani ten ne dlouhodobe.

O cmelakovi se zase rikalo, ze vzhledem ke sve vaze nemuze pri sve plose kridel litat - jenze, on to, chudacek, nevi a tak leta. DNS nevi, ze nemuze fungovat bez mezistatnich smluv - a tak funguje. No a Inernet, tomu zase uniklo, ze nemuze fungovat jen na zaklade neceho, co se jmenuje RFC - a taky potvora funguje.

Tak uz to tady, prosim, pane Kabate, nerozpitvavejte - mohl by si toho vsimnout a prestat fungovat. A ja pred tim jeste nutne potrebuju dostat jeden elektronicky dopis z Damasku.

Dekuji.

Nemyslím že by mail mohl zaniknout kvůli spamu, to je jako kdyby PC-čka měli zaniknout kvůli virům! Máme přece antiviry a antispamy. Používám SpamAssasina a ta úspěšnost v likvidaci spamů je přimo úžasná.

K tomu co pisete bych se pripojil, v podstate jsem chtel rict totez, ale byl jste rychlejsi... Bombasticky titulek, pak popis protokolu, ktery na mne pusobi jako experimentalni a spise teoreticka prace a v posledni jedne, dvou vetach ta podstatna informace o AMTP, ktery ma imho mnohem vetsi sance.
Nesouhlasim s tvrzenim autora clanku, ze SMTP obtizne garantuje funkcnost sluzeb ci autentikaci. Autentikace je dnes myslim hojne pouzivana a funkcnost... nevidim problem ve funkcnosti samotneho SMTP. Naopak, via SMTP lze routovat zpravu k adresatovi alternativnimi cestami (napriklad), dopravit mu ji na nejblizsi misto a pres SMTP lze dopravit zpet i hlaseni o doruceni zpravy (druhou veci je, zda to mail server / klient vyuziva).
Spise se v budoucnosti bojim, aby nejaky dementni politik nezahrnul spam a pod. do kategorie terorismu, protoze bojem proti nemu se uz dnes omlouvaji i valky proti celym narodum. Jen bych se nechtel dozit toho, abych musel novou emailovou adresu registrovat na nejakem "ministerstvu legalnich emailovych adres" a dostavat pak sice mene nabidek na generickou Viagru, zato nekolikrat prectenych FBI, CIA, NSA a kdovikym jeste. Zda se mi to dost uchylne na to, aby to nejaky blb mohl vymyslet a prosadit.
Mimochodem, znate nekdo techniku "Bayesian statistical filtering"? Nevim jak to spravne ohnout do cestiny, ale rozhodne mne to zaujalo http://www.paulgraham.com/better.html a mozna by tu nekdo o tom mohl neco napsat?

Bayesuv statisticky filtr je pomerne znama a v posledni dobe velmi sledovana technika pouzivana pro individualni filtering obtezujici posty. Implementovan je (napriklad) v Mozille a po nejake dobe trenovani dosahuje pomerne prijemnych vysledku.

S tym ministerstvom registracie mailovych adries nie ste az tak daleko od pravdy,az sa zavedie TCPA, nebude sa nic dat posielat z "nedoveryhodnych" zdrojov. A nie je to az taka vzdialena buducnost.
Ovsem ani TCPA nepomoze sirenu spamu, mozno prave naopak. Len to bude nastroj vhodny na cucanie prachov od pouzivatelov internetu. Vid. adresa: http://www.againsttcpa.com/

"az se zavede TCPA ..."

Podobnych napadu vzniak na svete za rok desitky - a na mnohych z nich se podileji i vyznamne spolecnosti. Presto se jich v praxi moc neprosadilo ...

Ono to NGMP při rozumném klientovi nemusí být tak blbý nápad. Přijde pošta od neznámého človíčka a můj klient mi nabídne: "Stáhnout" nebo "Zahodit" nebo "Zahodit a cokoliv od tohoto člověka vždy automaticky zahodit". Stáhnu si zprávu a mám možnost nastavit příznak "Od tohoto člověka vždy stáhnout" nebo "Od tohoto človéka vždy zahodit" (+ lze kombinovat s filtry na umístění zprávy vo vhodné složky). A pokud by tyto pravidla (vždy stáhnout nebo vždy zahodit) šly uploadnout na server mého ISP tak ani nemusím být online a problémy se projeví jen při první zprávé od neznámého človéka.

Tak a to je prave ten problem, ktery prinesl clanek. Michaji se zde hrusky a jabkama, protoze SMTP (a nasledujici) protokoly slouzi pouze k prenosu posty z bodu A do bodu B, tot vse. Po doruceni posty na cilovy server je to uz problem dalsiho software, ktery zpravy zkontroluje, odviruje, prefiltruje spam, roztridi do slozek... a umisti do schranky uzivatele. Odtud dal uz je to protokol zcela jiny, napriklad POP3, IMAP4... nebo treba taky zadny, pokud si to prectete primo na serveru.
Vsechny Vami popisovane veci jsou mozne i dnes, pokud to podporuje server a/nebo klient - nektere kombinace software tak uz funguji. Vim, ze uz kdysi kdy jsem pouzival Microsoft Exchange Server se pravidla z Outlooku ukladala (ta ktera sla, napriklad u notifikace uzivatele o prisle poste tim, ze to udela popup to nema smysl) primo na server a bezela tam bez ohledu na to, zda mi Outlook bezi. Kerio to dnes umi take, pravidla si muzete udelat primo na serveru, do ktereho to pada prave z trubky SMTP.
Takze myslim fakt, ze podobne funkce neimplementuji vyvojari do svych serveru / klientu svedci o necem jinam, nez o potrebe noveho protokolu pro transport posty. Oni by to nedelali ani tam a pokud by to uz novy protokol vyzadoval, tak by to zcela jiste nekdo predelal po svem (Microsoft?) a byli bychom zase tam, kde ted.

Kdyz uz je to mozne dnes, tak mi popiste jak udelate toto:
chci aby se pri prijmu posty mohlo zkontrolovat, ze posta jde z domeny, ktera odpovida odesilateli (mozno zkontrolovat podle DNS zaznamu pro NGMP pro danou domenu) a ze pokud nejaky spammer zkusi odeslat milion zprav, tak ze tyto nezatizi cilove SMTP servery ale jeho odesilaci NGMP server kde budou muset byt ulozeny do doby, nez si je prijemci vyzvednou (pokud mu je tam zrovna zlomyslne nenechaji jen at si zatizi server).

Právě ta nevyzvednutá pošta je mi trochu záhadou. Jsou v tom návrhu specifikována nějaká pravidla, jak dlouho má mail na serveru zůstat, pokud si ho příjemce nevyzvedne?

Cele to pusobi jako jakasi nedotazena akademicka fantasmagorie, vytvorena zrejme nejakym maniakem do IM klientu... A jinak provozovat "odesilaci" server musi byt v tomto pripade opravdu terno, o to bude urcite u ISP hrozny zajem, :-P

Myslim, ze muzeme zustat v klidu. Internet je sice zcela otevrene medium a kdyz je zachovana end-to-end konektivita, muze po nem behat ledacos, ale skutecne klicove aplikace jsou dukladne diskutovany v IETF a prijimany jako RFC.

Na webu IETF jsem o NGMP necetl, takze mam dojem, ze je prilis brzy na to, abychom ho brali vazne.

Uz jmeno autora, D. J. Bernstein, je vyraznym signalem o vlastnostech navrzeneho reseni - tedy - bude obsahovat skvele napady, soucasne ale bude neoddelitelne obsahovat i tezko akceptovatelne vady, pricemz DJB bude odmitat byt' jen diskutovat o tom, ze to vady jsou - a tim mene o moznosti jejich odstraneni. Tytez vlastnosti vykazuje QMAIL i DJBDNS, takze je lze logicky ocekavat i tady ...

Coz rozhodne neznamena, ze by nebylo dobre se na napady tohoto sverazneho genia opatrne podivat a rovnou je zavrhnout ...

Sice reauguji s krizkem po funuse, ale nedalo mi to.
Vseobecne souhlasim s tim, ze NGMP je diky tomu, ze zustava u odesilatele mene robusni, ale to ceho se hrozite je vlastne naopak. Staci se zamyslet :
Zjednodusene:
a) Poslu 1mb zpravu pres ISP1 10 lidem na serveru ISP2
b) Naoopak 1 z ISP2 posle 10 lidem zpravu na ISP1
Zatizeni diskoveho prostoru pro SMTP:
a) ISP1=0 ISP2=10mb
b) ISP2=10mb ISP1=0
Zatizeni diskoveho prostoru pro NGMP :
a) ISP1=1mb ISP2=cca 10kb (dorucena upozorneni)
b) ISP2=cca 10kb ISP1=1mb

Tak vo co gou ???!!!!

Pro pořádek je ovšem potřeba dodat, že tabulka množství přenesených dat pro obě varianty bude vypadat (téměř) přesně obráceně...

P.S. já jsem v tomto směru "ze staré školy", takže pro mne je znakem zvráceného myšlení už sama skutečnost, že někoho vůbec napadne posílat 1 MB mailem (předpokládám, že označením mb myslíte ve skutečnosti megabyte (správně MB) a ne milibit).

Pro poradek je ovsem treba dodat, ze obecne nemusi platit, ze pokud poslu zpravu deseti lidem na stejnem serveru, je tam tato zprava take desetkrat ulozena. Vim nejmene o jednom praktickem priklade (post.cz), ktery jednu doslou zpravu adresouvanou vice svym uzivatelum uklada jen jednou, obecne lze takovy postup ocekavat i u jinych systemu, kde se zpravy ukladaji jako jednotlive soubory (pak se take ulozi jednou a udela se prislusny pocet linku). Takze uvedena uvaha platit nemusi.

Krome toho, zminil jste jen jedno z mnoha rozdilnych kriterii - mnozstvi dat prenesenych po siti je u NMGM vyrazne vyssi nez u SMTP, navic je jejich prenos "online" a je tedy daleko citlivejsi na dostupnost a rychlost.

Porovnani tak nevychazi zdaleka tak jednoduse ...