Souhlasím, to je velká chyba, které se dopustili návrháři IMAPu. Existuje rozšíření pro Thunderbird, které místo posílání pošty přes SMTP prostě uloží odesílaný mail do správné složky. Pokud si vlastní server tak nastavíš, pak není problém tu poštu odeslat. Ovšem je to velmi nestandardní řešení, i když mě osobně by se líbilo, kdyby bylo všude.
No právě. Ale není k tomu důvod. Dřív se pošta četla přímo na serveru v terminálu, takže stačil jen SMTP pro posílání pošty mezi servery. Pak se ale objevily počítače, které nebyly k síti trvale připojené a bylo potřeba vymyslet něco nového. A vymyslela se jen půlka, druhá půlka zůstala.
Takže když se konfiguruje e-mailový klient, musí se konfigurovat dvě samostatné a naprosto nezávislé služby. Přitom řešení máme před sebou. Nikde jinde to tak nefunguje: můj Jabber klient umí jedním kanálem zprávy posílat i přijímat, na telefonování mi taky stačí jeden operátor a jedna SIM.
POP3 je něco jiného, ten neumí s poštou na serveru pracovat, je to jen jednosměrný kanál. IMAP umí klidně mail na server nahrát. Ale servery ho už neumí odeslat.
IMAP umoznuje aby se server s klientem dohodli na bambilionu ruznych rozsireni vcetne takovych veci jako je vyhledavani a trideni. Odesilani posty by uz mohla byt jen tresnicka na dortu. Rozhodne by to usnadnilo zivot lidem, kteri se pripojuji notebookem do ruznych siti a nemaji moznost pouzivat autentizovane SMTP.
Bohuzel ani DHCP neumoznuje poslat SMTP server jako option.
Nakonec vsichno skonci u web-mailu a problem bude vyresen.
Např. u DNS používání místních serverů chápu, je to dobrá distribuovaná databáze.
Ale používat místní SMTP server podle toho, kde zrovna jsem? To považuji za přežitek – chci posílat poštu přes svůj server, kde mám účet, znám otisk jeho TLS certifikátu, můžu mu věřit… Místní SMTP servery by měly smysl leda kdyby všichni šifrovali a podepisovali – pak bych např. při návštěvě v nějaké instituci mohl poslat e-mail přes jejich server a on by se doručil rovnou v místě, aniž by musel jít přes půl světa.
Místní smtp je krávovina od počátku. Nehodlam cpát svý maily nějakýmu troubelovi u kterýho visim na wifi a má "takysíť". Nehledě na to, že cíl by můj mail nevzal protože spf. Kromě toho jsou takový servery věčně na BL a dobře jim tak. Imap odesílání by lidem rozhodně nic neulehčilo. Máš smtp blokovaný v síti, abys neodesílal spam? No tak se blokne i imap a ani tu blbou poštu nestáhneš :-D. Kromě toho můžeš mít jinej smtp a jinej imap/pop server, třeba kvůli balancingu. Není snad pravidlo, že děláme soft, kterej umí jednu věc a dělá jí dobře? Smtp a imap se jaksi rozcházejí ve funkci, pro kterou jsou určeny. Microsoft má exchange, má tam padesát funkcí v jednom a ani jedna nefunguje. Borcí jsou to.
Ano, proto radši budeme konfigurovat v klientovi dva nezávislé protokoly a dvě nezávislé autentizace kvůli jedné službě. A aby toho nebylo málo, tak až budeme posílat megabajt fotek přes GPRS, počkáme si nejdřív minutu než se pomocí SMTP předají k odeslání a pak další minutu, než se IMAPem uloží do složky Sent. Tomu teda říkám systémové řešení…
Osobně jsem toho názoru, že shazovat někoho kvůli vlastní neschopnosti podívat se na problém s nadhledem, je řekněme hloupé. Víceméně prezentujete názor, že kritizovat funkčnost čehokoliv existujícího, je nesmysl. Jen si Vás dovolím upozornit na jednoduchou věc - z logického hlediska je naopak nesmyslný systém, kdy jeden mail odesílám 2x, poprvé přes SMTP protokol k doručení a podruhé ho přes IMAP ukládám do cílové složky.
Těžko bychom na internetu hledali něco, co je tak svázáno svou minulostí, jako je mail. A to samozřejmě v negativním slova smyslu. IMAP je toho zářným příkladem. Je to nesmírně komplexní protokol s obrovskou variablitou, takže je v podstatě každá implementace úplně jiná. Interoperabilita IMAP serverů je noční můrou provozovatelů veřejných mailových služeb.
Co se týče MAPI protokolu, vůbec se MS nedivím, že šli vlastní cestou.
Jeste by bylo fajn, kdyby ta jejich vlastni cesta fungovala aspon s jejich vlastnima vytvorama ... Takovy detail ... pridam uzivatele do AD, a v utlouku ho nekdo vidi hned ... nekdo trebas az za 14 dnu. To potesi ... reseni? Nejspis zadny.
A takovych veci je hafo. Kdyz si zapnu ten "hnusnej a blbej" imap, tak mam na disku par kB dat. Kdyz si zapnu utlouka s tim uzasnym M$ protokolem, tak mam na disku 5GB ... to potesi, specialne u stanic, ktery by z principu mohly bejt bezdiskovy ...
Pokud si vzpomínám, generuje Exchange dva typy globálních adresních listů, jeden pro online použití, druhý pro offline. Generování každého listu lze nastavit s různou frekvencí. To, který list se použije, je záležitost klienta a aktuálního stavu připojení k serveru. Neříkám, že s tím nejsou problémy, ani se nechci MS nijak zastávat za chyby v implementaci. Jen bych chtěl poukázat na to, že IMAP tuto schopnost nemá.
S porovnáním velikostí se mýlíte, aktuální verze klientů pro oba protokoly běžně poskytují možnost konfigurace stahování položek pro offline použití. A to obvykle na úrovni hlavičky/celé zprávy.
Každopádně bych se tu nerad dostal do role obhájce cesty MS, k tomu mám dost daleko. Jestli jsem si ale dovolil moc kritikou "hnusného a blbého" IMAPu, tak se poníženě omlouvám ;-)
Kdyz si neumis pri instalaci Outlooku odskrtnout "cache mode", tak se Ti holt vsechno stahuje na lokal. Za blbost se plati. V tomto pripade 5-ti GB diskoveho prostoru :-).
BTW, stejne se chova i IMAP. Muzes si to nechavat na serveru, nebo stahovat lokalne. Zalezi na tom, zda-li to potrebujes nebo nepotrebujes mit k dispozici offline.
Zeby to bylo tim, ze mail je navrzen ponekud jinak, nez se aktualne pouziva? On je totiz navrzen presne stejne, jako ... dramaticka pauza .... POSTA.
=> nekde mam svoji prijimaci schranku, do ktere mi postacka vhodi to, co je adresovano me. Ale kdyz chci neco poslat, muzu to vhodit do ... velke prekvapko ... LIBOVOLNE odesilaci schranky.
Jaksi se totiz predpoklada, ze nebudu svuj mail odesilat pres nejaky svuj mailserver na druhym konci planety, ale ze ho poslu pres ten, ktere provozuje ten, ke komu sem zrovna pripojen. A je to tak prave proto, ze se predpoklada, ze spojeni nemusi existovat stale.
To asi nikdo nerozporuje, jen netuším, co jste tím historickým vhledem chtěl říci.
Kdyby byl kdysi web navržen stejně, jako v klasickém světě fungují časopisy a noviny, asi by to taky nebylo úplně ideální. A posmívání se někomu, kdo by to následně kritizoval, by bylo asi tak stejně oduševnělé, jako Váš příspěvek.
Asi by sa zislo dat do pozornosti tento draft.
IMAP SUBMIT Extension
https://tools.ietf.org/html/draft-kundrat-imap-submit-02
Souhlas, bylo by fajn mít jeden protokol pro spojení: e-mailový klient → jeho poštovní server, přes který by se posílalo i přijímalo. A jiný protokol pro spojení jeden server → druhý server. Ale to je celkem jedno – pokud posíláš přes svůj server, tak se máš prokazovat jménem a heslem a server pak nemusí zajímat tvoje IP adresa a reverzní záznamy. A kromě toho je tu RFC 6409 – Message Submission for Mail – a port 587, který je vyhrazený pro tyto účely. Port 25 by pak zůstal čistě pro doručování z jednoho serveru na druhý.
I u vlastního serveru, na který odesílám pomocí submission mě rozčiluje, že stejná zpráva se posílá dvakrát. A pak mě taky štve kreativita některých lidí, kteří poštu s firemní adresou odesílatele posílají přes svého lokálního ISP a diví se, že není občas spolehlivě doručena.
Přitom aspoň jedna serverová implementace existuje:
http://www.courier-mta.org/imap/INSTALL.html#imapsend
Je škoda, že nedostála nějaké širší implementaci, podle mě je to to správné systémové řešení, jak vzdáleně obsluhovat e-mailovou schránku (což je účel, ke kterému IMAP slouží). Odesílání pošty je přece základní obsluhou takové schránky.
Jo, outbox courieru jsme roky používali ke spokojenosti obchodníků kteří nemuseli řešit SMTP server. Stávající dovecot to sám o sobě neumí (i když obezlička typu http://www.dovecot.org/list/dovecot/2007-April/021457.html není složitá).
Vyřešili jsme to smtp autorizací a maily se posílají přes firemní SMTP server i zvenku. Samozřejmě se může stát, že má síť zablokovaný port 25 ven.
Samozřejmě se může stát, že má síť zablokovaný port 25 ven.
Právě proto je přesně pro tyto účely normalizována služba Submission, port 587, který by blokován být neměl, resp. jeho blokování nemá pro správce sítě takový význam jako blokování odchozího portu 25. Třeba v Postfixu stačí submission jen odkomentovat v master.cf. Vedlejším efektem je, že na portu 25 je pak možné zcela zakázat autentizovaný přístup, což trochu překazí plány hádačům hesel. Samotného mě překvapilo, kolik jich chodí hádat hesla na port 25 a jak málo naopak jich zkouší heslo na 587.