KDE4 KMail a Gmail pomocí IMAP a SMTP

21.9.2008 17:48 | Přečteno: 3189× | Linux |

Po několikaletém používání webových mailových klientů jsem se rozhodl vyzkoušet, co umí mailový klient, který je součástí mého oblíbeného DE, tedy kmail. Nedá se říct, že bych byl s webovým klientem gmailu nějak nespokojen nabízí mi vše co potřebuji, navíc se pravidelně připojuji z několika počítačů, takže má webový klient výhodu v konzistentnosti. Přece jen ale převážila zvědavost, takže jsem se rozhodl dát KMailu šanci.

Po chvíli brouzdání na google help jsem si vybral jako preferované protokoly IMAP a SMTP. S nastavováním jsem měl pár menších problémů, které jsem vyřešil nějakým tím hledáním na googlu a zkoušením. Abych toto nemusel někdy v budoucnu absolvovat znovu, rozhodl jsem se své poznatky uložit tady.

Nastavit IMAP nebylo těžké. Něco se dá najít na google help, který ale neobsahuje konkrétní návod pro KMail. Jediné, co nemusí být z obecných údajů od google jasné, je metoda autentizace v záložce bezpečnost, kde se také nastavuje šifrování SSL. Dialog ale obsahuje šikovné tlačítko "Zjistit, co server podporuje," které toto řeší. Výsledkem byla volba Čistý text.

Pak zbývalo ještě nastavit SMTP. S tímto jsem nečekal velké problémy, avšak byl jsem trochu nemile zaskočen. Jednak už na google help se mluví o dvou portech, stejně jako se mluví o TLS i SSL (některé klienty podle googlu vydávají TLS za SSL). Hezké je právě to slovo některé, to se pak dobře vybírá.

Rozhodl jsem se ještě trochu zagooglit, zda nenajdu nějaký návod, přičemž jsem našel toto. Jazyku, ve kterém to je napsané sice nerozumím, ale přiložené snímky oken jsou všeříkající. Nastavil jsem tedy port 465, šifrování SSL a autentizaci PLAIN, jak obrázky doporučovaly.

Poté jsem se rozhodl vše vyzkoušet. IMAP fungoval krásně, ovšem odesílaný mail vyhodil jakousi hlášku s mými přihlašovacími údaji a oznámením, že dokud chybu neopravím, mail zústane v přihrádce k odeslání. Po několikanásobné kontrole, která mě ujistila, že se mé nastavení skutečně shoduje s návodem, že je heslo i uživatelské jméno stejně jako adresát správně, jsem se jal dál hledat na googlu.

Tentokrát jsem se dostal k několika hlášeným bugům, ze kterých tento pasoval nejvíce. Zkontroloval jsem tedy SASL, avšak vše bylo v pořádku.

V tuto chvíli mi už začínaly docházet nápady, zvláště poté, co jsem ještě zkusil druhý doporučovaný port a pak i TLS šifrování, ačkoliv jsem při hledání stále narážel na lidi, kteří tvrdili že správné nastavení je SSL.

Poté, co jsem objevil kdesi na třetí stránce výsledků hledání další návod, rozhodl jsem se tomu dát poslední šanci, tentokrát s heslem, když se něco nedaří, začni úplně znova.

Poté co jsem smazal příchozí i odesílací účty, vytvořil novou identitu, smazal tu původní a smazal i ./kde4/share/apps/kmail, jsem nastavil port na 587, šifrování TLS, autentizaci PLAIN a jméno v záložce všeobecné shodné s mou emailovou adresou.

A tentokrát se zpráva odeslala.

       

Obrázky

Komentáře

[Scarabeus IV]

Tohle bylo celkem jednoduchy ;]
Ale zaboha nemuzu prinutit email odesilat podepsane maily s prilohou, normalni mail ok ale kdyz je tam priloha tak chcipne kgpg... :(

[Luk]

GMail neumí TLS na standardním portu 25 (pomocí STARTTLS)?

Jinak KMail jsem před časem dočasně zavrhl, protože měl s IMAPem problémy - často tuhl tak, že ho bylo potřeba sestřelit násilím.

[Nicky726]

Zdá se že používají jiný port, právě ten 587.

No zatím tj. během dneška mi párkrát zatuhl při přejmenování gmailových štítků a jejich přesunu a párkrát mi při tom spadl.

[Luk]

Zdá se že používají jiný port, právě ten 587.

To jsem pochopil. Jen mě překvapuje, že to řeší takto, protože SSL/TLS na samostatném portu je spíš historický relikt (z dob, kdy nebylo rozšíření SMTP pro TLS), než aby mělo smysl to dnes používat (tím spíš na nestandardním portu - port 587 je sice podle RFC 2476 určen pro Message Submission, ale když už se používá 25, pak by se měl používat port 465).

[Zdeněk Burda]

Jiný port než 25 se docela hodí, pokud se připojujše každou chvíli z jiné sítě (notebook na cestách). Spousta správců blokuje 25/tcp.

[Luk]

Takoví správci by zasloužili natlouct - přesně kvůli nim se na Internetu prasí v číslech portů. Chápu, že se třeba chtějí bránit proti datovému toku generovanému červy atd., ale pak to vede k tomu, že vznikají věci jako Skype, které za cenu všelijakých čuňáren taková omezení obcházejí.

[Dan Ohnesorg]

Casto neni zadouci aby STARTTLS bylo na portu 25, protoze potom se pouzije i pro s2s komunikaci a pokud nemate certifikaty podepsane duveryhodnou autoritou, tak prestanou maily chodit. Prave proto je tam dalsi port, ktery je urcen pro c2s komunikaci a dava mnohem vetsi moznosti vyhrat si s konfiugraci.

Jinak ten odkaz "nekteri" v navodu je google je dle ocekavani na outlook. Ten je totiz velmi zmateny a nevi co dela a kdy to dela, navic to zacal od verze 2003 delat uplne jinak.

[Luk]

protoze potom se pouzije i pro s2s komunikaci a pokud nemate certifikaty podepsane duveryhodnou autoritou, tak prestanou maily chodit.

Tohle je pravda jen ve dvou případech - buď když je TLS povinné, nebo když je odesílající server blbě nakonfigurován (případně s hodně starou verzí nějakého MTA, kde když selže TLS, tak se na doručení zcela rezignuje).

Navíc by to neměl být případ Googlu, pro něj snad není problém mít důvěryhodný certifikát.

Prave proto je tam dalsi port, ktery je urcen pro c2s komunikaci a dava mnohem vetsi moznosti vyhrat si s konfiugraci.

Pak by se měl ale používat i pro běžné (nešifrované) odesílání, jinak se do toho zanáší bordel a komplikuje se nastavování klientů (tedy ono už vůbec použití jiného portu než 25 komplikuje konfiguraci).

[Dan Ohnesorg]

Tohle je pravda jen ve dvou případech - buď když je TLS povinné, nebo když je odesílající server blbě nakonfigurován (případně s hodně starou verzí nějakého MTA, kde když selže TLS, tak se na doručení zcela rezignuje).

Tohle je slozita filozoficka otazka. Mam na protistranu, ktera je schopna dolozit svou identitu a dolozi ji umyslne spatne hledet stejne jako na takovou, ktera to neumi? A jak to mam udelat, mam resetnout SSL spojeni a otevrit nove plain text a nebo mam jet dal po tom SSL?

Pak by se měl ale používat i pro běžné (nešifrované) odesílání, jinak se do toho zanáší bordel a komplikuje se nastavování klientů (tedy ono už vůbec použití jiného portu než 25 komplikuje konfiguraci).

Myslel jsem 587, 465 je fakt artefakt. Na 587 zvladne starttls i ten outlook.

[Luk]

Tohle je slozita filozoficka otazka. Mam na protistranu, ktera je schopna dolozit svou identitu a dolozi ji umyslne spatne hledet stejne jako na takovou, ktera to neumi? A jak to mam udelat, mam resetnout SSL spojeni a otevrit nove plain text a nebo mam jet dal po tom SSL?

Z hlediska bezpečnosti by bylo o něco lepší jet dál po nedůvěryhodném SSL (protože to může zabránit aspoň odposlechu na trase), ale na druhou stranu by to teoreticky mohlo někoho "ukolébat", že se použilo šifrování a všechno tedy musí být v pořádku. Např. Postfix to standardně řeší tak, že když se po STARTTLS objeví problém (ať už kvůli certifikátu nebo z jiných důvodů), tak to zkusí znovu v plain textu, čili to převede na situaci, jako kdyby cílový server TLS vůbec nepodporoval.

Myslel jsem 587, 465 je fakt artefakt.

Ale pak není potřeba z tohoto ohledu port 25 vůbec řešit a pro MUA nechat jen 587.

Na 587 zvladne starttls i ten outlook.

To ano, ale musí se tam to číslo portu nastavit.

[Dan Ohnesorg]

Ale pak není potřeba z tohoto ohledu port 25 vůbec řešit a pro MUA nechat jen 587.

Ano a tak je to asi i spravne. Nevim jestli v dobe, kdy se navrhoval design SMTP nekdo pocital s tim, ze klient neco posle pres port 25, tehdy se na to pouzival prikaz sendmail, ktery komunikoval s lokalnim sendmail demonem tak, ze injektoval zpravu do fronty, takze 25 mohla byt od zacatku zamyslena jen pro s2s a klientum to holt zapomeli rict

Jinak rozhodne konfigurovat SASL a podobne vychytavky mi prijde mnohem cisti na 587, jediny problem je vysvetlit prumernemu uzivateli, ze si musi v outlooku zmenit cislo portu. Obykle to pochopi az kdyz narazi na nesolidniho providera, ktery mu blokuje porty.

[Luk]

Jinak rozhodne konfigurovat SASL a podobne vychytavky mi prijde mnohem cisti na 587

To asi ano, ale SSL by bylo žádoucí používat i pro S2S komunikaci - čím méně "uší", tím lépe. Nic to samozřejmě nezaručuje (odposlouchávat se dá i na serveru, resp. je to ten častější případ), ale i tak.

[Dan Ohnesorg]

Zadouci by to bylo, ale doba na to jeste nenazrala. Nyni to resim tak, ze pro smery ve kterych hrozi pruchod nejakeho citlivejsiho mailu pouzivam openvpn tunely a maily pres ne zenu skrz transporty. Ale to je samozrejme reseni nasaditelne jen v uzavrenych skupinach, jako kdyz mate firmu s pobockami.

Do budoucna by z toho mohlo byt jedno z antispamovych opatreni, maily, ktere prijdou od klienta s duveryhodnym certifikatem, budou dostavat mene bodu nez ty od nahodnych stanic, neschopnych autorizace certifikatem ve startu ssl spojeni. A Verisign se na tom uzasne napakuje

[Luk]

Zadouci by to bylo, ale doba na to jeste nenazrala.

Spíš to vypadá, že zraje doba na to (nebo spíše dávno nazrála), aby se šifrovaly samotné zprávy, aby se cizí uši nastražené kdekoli na celé trase nedostaly k obsahu zpráv.

A Verisign se na tom uzasne napakuje

Naštěstí existují i levnější, a přitom dostatečně důvěryhodné certifikační autority (jejichž kořenové certifikáty jsou součástí instalací většiny MTA a MUA). Jen aby to pak ale neskončilo tak, že certifikát podepsaný od Verisignu bude mít méně bodů než ty ostatní autority

[Dan Ohnesorg]

Spíš to vypadá, že zraje doba na to (nebo spíše dávno nazrála), aby se šifrovaly samotné zprávy, aby se cizí uši nastražené kdekoli na celé trase nedostaly k obsahu zpráv.

Kazde z tech reseni je urcene pro mirne odlisny okruh problemu. SMTPS teoreticky zajisti duvernost prenesene zpravy i v pripade, ze uzivatele nemeli moznost vymenit si klice a nebo v pripade, ze email je poslan na 1000 adres soucasne a nebylo by prakticke sifrovat kazdou z tech kopii zvlast.

Naštěstí existují i levnější, a přitom dostatečně důvěryhodné certifikační autority (jejichž kořenové certifikáty jsou součástí instalací většiny MTA a MUA). Jen aby to pak ale neskončilo tak, že certifikát podepsaný od Verisignu bude mít méně bodů než ty ostatní autority

Bavime se jiste o tech vlastnenych Verisignem

Nepochybne to tak skonci, staci se podivat na EV certifikaty, ty vystavuje pouze exkluzivni klub Verisign a comp. a takovety petidolarove autority mezi sebe nepusti, i kdyby v prohlizeci byly 100x. Na druhou stranu i to EV dava smysl, protoze pamatuji doby, kdy uplne bezny serverovy certifikat byl vystavovan s validaci odpovidajici dnesnimu EV a potom uz ta pravidla jen erodovala a devalvovala. Dneska uz je to tak spatne, ze Thawte auditori u SSL Webserver vubec nevolaji zakaznikum a pokud ano, tak ne na cisla ziskana od treti strany, ale na cisla uvedena v zadosti.

[Přemek Vyhnal]

Umí nějaký klient seskupovat přijaté i odeslané zprávy do jedné „konverzace“ tak jak to dělá gmail? Snažím se přestat používat webmail ale takovéhle věci mi chybí.

[Luk]

AFAIK to by to snad měl umět Chandler, ale je to takový lenoch, že ho nejde moc doporučit.

[Daniel Kvasnička ml.]

Me by toho chybelo tedy mnohem vice. Pres co bych se asi neprenesl, je mutace labelu na IMAP slozky (z principu blbost, stejne jako je IMHO blbost vubec postu do slozek organizovat) a fakt, ze KMail ci jini asi tezko bude umet respektovat barevne nastaveni labelu a u kazde konverzace ty barevne labely ukazovat... Quick Links jsou ve web rozhrani taky super. A umi KMail syncnout kontakty z Gmailu do KAddressBooku nebo jak se ta bestie KDEckarska jmenuje?...

[Nicky726]

Co jsem zatím lehce zkusil, lze z Gmailu exportovat kontakty jako vcard a to pak otevřít KAddresBookem. Plnohodnotnou synchronizaci kontaktů zdá se, že Gmail neumí.

[Heron]

Na to stači odeslanou poštu ukládat do stejné složky jako přijatou. Zobrazení podle vláken by mělo zařídit to, co potřebujete.

(Nebo si to poslat jeste v Bcc )

[Michal Vyskočil]

Umí nějaký klient seskupovat přijaté i odeslané zprávy do jedné „konverzace“ tak jak to dělá gmail? Snažím se přestat používat webmail ale takovéhle věci mi chybí.

Kmail to umí. Stačí se podívat do Složka/Vlastnosti.

[Luk]

Opera to umí také, jak jsem teď zjistil.

[Petr Tomeš]

Thunderbird umí něco podobného - stromová vlákna, ale přijde mi, že Gmail má lépe dotaženou funkci rozpoznávání konverzací. Vlastně je docela zajímavé zkusit používat Gmail jako aplikaci přes Mozilla Prism nebo Google Chrome/Chromium s ikonou pro rychlý přístup na ploše/panelu na obrazovce. V těch nových verzích prohlížečích je ta webová aplikace skutečně velmi rychlá, vyhovuje mi ergonomie ovládání i různé vymoženosti nedostupné v e-mailových programech (ty se dají ještě dále rozšířit různými doplňky jako třeba BetterGmail apod.). Je to prostě trochu jiný styl práce, záleží na tom, jak si kdo zvykne.

[Luk]

Thunderbird umí něco podobného - stromová vlákna

Ale AFAIK jen v rámci složky.

[Petr Tomeš]

Zkusil jsem to ještě znovu a funguje to nějak divně, nevidím tam odchozí poštu a teď to neukazuje vůbec nic. :/ A asi to opravdu funguje jen v rámci složky.

[Tomáš]

Podle mne to dělá google pěkně blbě, protože to dělá podle subject. Mělo by se to dělat nějak jinak, specializovaní klienti pro čtení poštovních konferencí to umí (mám dojem, že nějak trasují messageid, nebo tak něco) Jinak, v kmailu se mi to řadí stejně jako v gmailu. když to tam nějak vyklikám.

[Luk]

Podle mne to dělá google pěkně blbě, protože to dělá podle subject.

Ale fuj, to snad ne!