Je to vsechno moc hezke, take rikam, ze neni nad klasickou unixovou prikazovou radku. Jenomze v pripade mailovani je tu problem - casto prijde obrazek nebo HTML stranka a to je pak textovy rezim VELMI omezujici. Obavam se, ze to je vetsi prekazka nez pohodlnost.
Jeste dalsi problem s klasickou koncepci - jak zjistit kolik zprav bude prijimano, kolik kb jiz bylo prijato, atd? Pise se to nekam do logu, takze by to spravilo tail -f?
V tomto clanku by melo byt i to ze textove klienty jsou pro "geeks", protoze bezny uzivatel by ho asi tezko ovladal a jeste hur by treba prohlizel obrazky z prilohy. Pro bezne pouzivani lidem kteri jsou zvikly na Outlook Express doporucuji KMail ktery vypada opravdu hezky a je soucasti KDE 2.
Mno, ja mam dojem, ze se jedna spis o to, jak beznemu userovi admin nakonfiguruje mime a tak. Nevim nevim, ale ja si prohlizim obrazky v muttu pomoci <ENTER>. Akorat je treba poslat do pRd3l3 outlookisty, kteri posilaji jpegy jako application/octet-stream, to je od nich hrozne slusny...
Nepovazuji se za nejakeho pocitacoveho geeka ani za nic podobnyho. V Linuxu jsem vicemene zacatecnik, ale jedna z prvnich veci, co se mi na Linuxu zalibila, byl Mutt :-) Myslim, ze je to jenom na uzivateli, jestli je ochoten "investovat" prvni tyden na seznameni se s klientem. Pak je ovaladani mnohem vice pohodlne a hlavne mnohem rychlejsi nez v Outlook Express apdb.
A html stanky a grafika? A co /etc/mailcap (resp. ~/.mailcap), ktery vse resi(aspon zatim me, jsem vazne zacatecnik :-) ). Mozna je prace s grafikou o trosku mene pohodlnejsi, ale ze by to bylo, jak rikate "VELMI omezujici", mi zas az tak nepride.
Docela by mne potesilo (a jiste by to uvitali i jini) spise neco na zpusob "ruzna reseni prace s postou pres vytacene spojeni". Spise vsak formou
Varianta 1.fetchmail+sendmail+mutt
Varianta 2. ...
Mozna by i mnozi "radoby geeks" zirali, jak se to da udelat. Naproti tomu manual k Masqmailu si umim precist i sam (presto dik za typ :-))
je pravda, ze fetchmail sam postu do mailboxu nedorucuje, ale nepotrebuje k tomu lokalni smtpdaemon, staci mu mda ve stylu procmail (celkem rozsirena vec).
v konfiguraci (~/.fetchmailrc) se to nastavuje treba takto:
poll pop3.mvcr.cz with proto POP3 user "dastych" pass "linuxrulz" is jirka mda "/usr/bin/procmail -f -"
aspon me tak posta chodi porad s tim, ze jsem jeste nenasel vhodny MTA, takze pouzivam neco-nic-neco-nic atd.
jsem uzivatel WIN., ale s prikazovou radkou a ruznym nastavovanim jsem si taky chvilku hral. Kdyz ctu tento clanek, uplne ziram. Tohle vsechno kvuli tomu, aby chodil mail? To je presne to, proc si instaluji novy Mandrake a ne treba RedHat, protoze mi nabizi prijemne a intuitivni zachazeni a hlavne konfiguraci. Radsi obetuju trochu funkci, nez abych se pachtil nekolik hodin s instalaci text klienta.
Jen muj nazor.
jo, klikaci klienty schopne vest pop3 ci imap dialog jsou hezke, ale klasicke "unixove" reseni, kdy se vsechna posta stahuje do lokalniho mailboxu (ktery by nemel zustavat bez povsimnuti), a otdut ji muzou brat ruzni klienti (textovi i graficky). jmena postovnovnich serveru / jmena /hesla jsou pak uvedeny prave na jednom miste (napr. konfigurak fetchmailu). o pravidelnost se postara treba cron.
u odchozi posty je to podobne - je dobre mit nakonfigurovany lokalni mta, ktery postu bud preposila nebo dava do fronty (offline). adresa smtp serveru je pak taky jen na jednom miste a vsichni klienti odesilaji pres localhost.
a nejen ze je to elegantnejsi, ale clovek pri tom nutne
musi pochopit, jak to funguje. vyssi internetova gramotnost jedince pak bude prinosem k prosperite celeho lidstva. zamyslete se nad sebou.
Myslim, ze tato snaha prosazovat 20 let stara "unixova reseni" je presne ten duvod, proc spousta lidi dava od Linuxu ruce pryc. Nevim, ale ta takzvana "flexibilita" mi pripada spise jako strasliva tezkopadnost. Bezne pouzivam dve postovni schranky, muzu odesilat z jedne nebo druhe, kdyz jsem pryc, mam k nim pristup pres webmail a to vsechno bez ztraty casu s konfigurovanim fetchmailu a prepisovani adres v MTA... Vetsina lidi chce proste aby jim fungoval mail, ne se ucit SMTP, POP, IMAP a administrovat unix... Nebo taky kazdy ma studovat teorii elektromagnetickeho pole az si bude chtit pustit televizi ?
staci naistalovat
- postfix (v konfiguraci se nastavi presne 2 radky: defermail a smarthost - je to ve FAQ, jak se to presne napise - pod tematem DIALUP) a
- fetchmail (existuje graficka utilita fetchmailconf, ktera se na vsecko vypta)
pak si muzete postu vyrizovat, jak chcete kterymkoliv unixovym klientem (vcetne outlookoidniho evolution)
a poslani zaridite tlacitkem na gnome-panelu, ktere zavola 'sendmail -q' a prijmuti 'fetchmail'
je tezkopadne vyse uvedene reseni, kdy ma jeden program na starost jednu cinnost, nebo reseni pres postovniho klienta, ktery krome zobrazovani a psani zprav umi nekolik protokolu pro odesilani/prijmani posty, v offline stavu dava postu do fronty a nedejboze treba zkousi komunikovat pres sifrovany kanal?
jde o to, ze na jednom stroji je casto k dispozici
vic klientu (neb uzivatele jsou rozezrani), coz by v druhem pripade nutne vedlo k tomu, ze mate nekolik
verzi kodu a konfigurace, ktere vsak delaji to same
(s rozdily v chybach a dalsich nepodstatnych detailech).
na druhou stranu pokud admin rozumne nakonfiguruje odchozi postu (treba i s prekladem adres) a uzivatel fetchmail, pak muzou mit vsichni klienti machine-wide konfiguraci s odesilanim pres localhost a prijmem s lokalniho mailboxu. adminovi by to nemelo delat potize
(je to jeho prace a odchozi smtpserver zavisi na pocitaci a siti, do ktere je pripojeny, nikoliv na
tajnych pranich uzivatelu)a uzivatel musi jen uvest / naklikat, jaky ma e-mail a odkud chce stahovat postu. oba vsak uvedenou cinnost provedou prave jednou.
k te televizi: predstavte si, ze mate jednu televizi (=klient) a signal z vice zdroju(=schranky) (2 anteny). koupite si slucovac(=fetchmail) nebo budete prohazovat kabel? a co kdyz si koupite druhou televizi(=jiny klient)? koupite rozbocovac(=vyuziti lokalniho mailboxu) nebo dalsi 2 anteny(=naklikani konfigurace stejne jako u 1. klienta)?
Jak sam rikate, cele toto reseni je zalozeno na system-wide konfiguraci. Jenomze prave to je nejvetsi slabina unixoidnich maileru : predpoklada se totiz, ze vsichni uzivatele pouzivaji jeden a tentyz mailovy servis (ten, ktery sysadmin nainstaloval). Jenomze co kdyz nekdo chce krome toho mit pristup i k jinym, externim schrankam ? To znamena je redirigovat, nebo krome "standardniho" nastaveni pouzivat *navic* MUA ktery se na ne muze napojit pres POP... Dale : znamena to, ze veskery mail se spravuje lokalne a neni k nemu mozny pristup zvenci. V pripade textoveho klienta je tu sice moznost ho pouzivat nadalku pres telnet nebo ssh, ale to neni vzdycky mozne ani zadouci. O komfortu uzivatele nemluvne.
A co chudak obycejny uzivatel, ktery chce pouzivat mail na svem pececku doma ? Misto aby si spustil evolution nebo kmail nebo..., dal tam adresu sveho konta POP a hotovo, jeho prvni dojem z linuxu budou dlouhe, slozite a - pro neho - nesrozumitelne konfigurace, a to vsechno proto, aby chodil mail ! On totiz nema admina, ktery to za nej nastavi, ani nebude pouzivat deset ruznych klientu.
ale vzdyt stahovani posty z externich schranek resi fetchmail. a k mailu v lokalnim mailboxu se jde vzdalene dostat celkem v pohode, kdyz si rozjedete pop/imap daemon (nebo treba nejakou prasarnu pres web). to obludne slozite reseni se ve skutecnosti vyznacuje predevsim svou jednoduchosti (i po strance konfigurace) a take jistou eleganci. na tom, ze kdyz chce clovek neco pouzivat, tak by mel vedet jak to funguje, nevidim nic zvlastniho. k tomu adminovi: pod unixem je potreba, obvykle je to osoba co zna rootovo heslo.
Vy znate technologie na kterych funguje lednicka, televize, radio, auto, pocitac? Jejich motory, jejich elektronika? Znate technologie jak se vyrabi elektrina, jak funguji vysilace televize a radia, mobilniho telefonu? Vy znate fyzikalni zakony a zakonitosti na nichz je vsechno toto postaveno? Pokud ano, jste bezesporu naprosty genius. Pokud ne, jak to muzete pouzivat, vzdyt "na tom, ze kdyz chce clovek neco pouzivat, tak by mel vedet jak to funguje, nevidim nic zvlastniho".
:o))))
je tezkopadne vyse uvedene reseni, kdy ma jeden program na starost jednu cinnost, nebo reseni pres postovniho klienta, ktery krome zobrazovani a psani zprav umi nekolik protokolu pro odesilani/prijmani posty, v offline stavu dava postu do fronty a nedejboze treba zkousi komunikovat pres sifrovany kanal?
jde o to, ze na jednom stroji je casto k dispozici
vic klientu (neb uzivatele jsou rozezrani), coz by v druhem pripade nutne vedlo k tomu, ze mate nekolik
verzi kodu a konfigurace, ktere vsak delaji to same
(s rozdily v chybach a dalsich nepodstatnych detailech).
na druhou stranu pokud admin rozumne nakonfiguruje odchozi postu (treba i s prekladem adres) a uzivatel fetchmail, pak muzou mit vsichni klienti machine-wide konfiguraci s odesilanim pres localhost a prijmem s lokalniho mailboxu. adminovi by to nemelo delat potize
(je to jeho prace a odchozi smtpserver zavisi na pocitaci a siti, do ktere je pripojeny, nikoliv na
tajnych pranich uzivatelu)a uzivatel musi jen uvest / naklikat, jaky ma e-mail a odkud chce stahovat postu. oba vsak uvedenou cinnost provedou prave jednou.
k te televizi: predstavte si, ze mate jednu televizi (=klient) a signal z vice zdroju(=schranky) (2 anteny). koupite si slucovac(=fetchmail) nebo budete prohazovat kabel? a co kdyz si koupite druhou televizi(=jiny klient)? koupite rozbocovac(=vyuziti lokalniho mailboxu) nebo dalsi 2 anteny(=naklikani konfigurace stejne jako u 1. klienta)?
Snazim se prejit od netscapa k muttu, ale neumim vyresti jeden problem:
Postu si stahuju popem na spoustu mist (domu,do skoly,do prace,..) a ze servru ji nemazu. U netscapu je to v poradku, protoze si v souboru popstate udrzuje id zprav, ktere uz stahl a stahuje jenom novejsi. Nevim, jak presvedcit fetchmail, aby delal neco podobneho (kdyz mu dam fetchall, stahne pri kazdem spusteni vsechny mailu co jsou na servru, bez toho stahuje pouze maily, ktere jsem jeste nikam nestahnul).
Neznate nejaky program, ktery tohle umel? (zkousel jsem fetchmail a getmail). Upravit fetchmail beru jako posledni moznost.