Sztuczki z pocztą -
suplement

Nie spodziewałem się, że cykl tekstów traktujących o zaawansowanych możliwościach konfiguracji poczty elektronicznej na kontach Unixowych, który ukazał się w ostatnich trzech numerach MI, spotka się z tak ogromnym zainteresowaniem Czytelników. Otrzymałem wręcz lawinę listów; odpowiedzi na część z nich zamieściliśmy w rubryce "Listy", w niniejszym tekście natomiast chciałbym odnieść się do paru bardziej ogólnych spraw, do zajęcia się którymi skłoniły mnie opisane w listach Czytelników problemy.

Vacation, ale nie ten!

Po opublikowaniu w pierwszym tekście z cyklu "Sztuczki z pocztą" (MI 2/99) informacji o tym, w jaki sposób wysyłać automatyczne odpowiedzi na listy przy użyciu programu vacation, otrzymałem szereg listów, których autorzy skarżyli się na to, że na ich serwerze program nie działa tak, jak to opisałem w artykule. "Po wpisaniu w linii poleceń 'vacation' nie dzieje się nic" - pisze czytelnik. "Nie uruchamia się żaden edytor, nie ma również żadnych pytań. Co dalej?"

Istotnie, pisząc swój tekst nie sprawdziłem tego, że w części systemów unixowych zawarty jest inny wariant programu vacation, nie wyposażony w takie ułatwienia, jak wersja opisywana przez mnie (pochodziła ona z systemu Solaris firmy Sun). Mogło to rzeczywiście zdezorientować Czytelników, którzy mieli okazję natknąć się na tę "uproszczoną" wersję programu, gdyż w wersji tej wszystkie czynności przygotowawcze niezbędne dla skonfigurowania automatycznych odpowiedzi musimy niestety wykonać ręcznie.

Najpierw za pomocą dowolnego edytora (np. joe) musimy utworzyć w swoim katalogu macierzystym plik o nazwie .vacation.msg (znowu kropka na początku nazwy). Piszemy więc

     joe .vacation.msg
i wpisujemy do pliku treść odpowiedzi, jaką program ma wysyłać, wraz z nagłówkami, które chcemy w niej umieścić - możemy tu posłużyć się wzorem przedstawionym na ilustracji w pierwszej części tekstu. Powinniśmy podać przynajmniej nagłówki "From:" oraz "Subject:"; należy przy tym pamiętać, że nagłówki od treści odpowiedzi powinny być oddzielone przynajmniej jednym pustym wierszem.

Następnie - również za pomocą tego samego edytora - tworzymy w swoim katalogu plik .forward zawierający jeden wiersz o treści prezentowanej już w pierwszej części artykułu:

     \nazwa,"|/usr/bin/vacation nazwa"
gdzie "nazwa" jest nazwą naszego konta na serwerze. Należy przy tym sprawdzić, czy program vacation faktycznie znajduje się w katalogu /usr/bin (polecenie whereis vacation), w niektórych systemach może on bowiem znajdować się w innym katalogu, np. /usr/ucb.

Jeszcze zanim wykonamy powyższą czynność, powinniśmy utworzyć początkowy, pusty plik bazy adresów, w którym program będzie zapisywał adresy nadawców przychodzących do nas listów (zob. pierwszą część artykułu); w tej wersji programu wykonujemy to komendą "vacation -i" - zwróćmy uwagę, że parametr wywołania programu zapisany jest tutaj za pomocą małej litery, a nie dużej, jak w wersji opisywanej uprzednio. Komendę tę powinniśmy także powtórzyć przed każdym kolejnym zastosowaniem programu dla "wyczyszczenia" listy zapamiętanych adresów.

I już! Od tej pory automatyczne odpowiedzi powinny działać. Chcąc je wyłączyć, wystarczy po prostu skasować plik .forward (poleceniem rm), lub - aby przy kolejnym użyciu tej możliwości nie trzeba było wpisywać od nowa jego treści - zmienić jego nazwę na inną (poleceniem mv).

Omawiana tu uproszczona wersja programu vacation na ogół nie akceptuje też innych parametrów wywołania, o których wspominałem w pierwszym artykule - w szczególności parametru -t, określającego minimalny czas, po jakim po raz drugi zostanie wysłana automatyczna odpowiedź do tej samej osoby. W niektórych systemach (np. HP-UX) w ogóle nie ma możliwości zmiany domyślnego odstępu czasowego wynoszącego tydzień; w innych, jak np. OpenBSD, można to zrobić tylko przy inicjowaniu bazy adresów komendą "vacation -i", podając w niej dodatkowy parametr -r; przykładowo, komenda "vacation -i -r 14" ustawia odstęp czasowy pomiędzy poszczególnymi odpowiedziami na 14 dni.

W listach od Czytelników pojawił się również "egzotyczny" przypadek systemu (UNISYS UNIX SVR4), który zamiast opisywanego programu vacation zawierał skrypt shellowy o tej samej nazwie, realizujący analogiczną funkcję, ale w zupełnie inny sposób (nie korzystając z pliku .forward), i wywoływany oczywiście z zupełnie innymi parametrami... (co ciekawe, system ów zawierał także - w katalogu /usr/ucb - wersję programu identyczną z opisywaną przeze mnie, ale nie dało się jej skutecznie użyć). Dlatego zawsze warto sięgnąć do instrukcji programu, dostępnej poprzez polecenie man vacation - zawiera ona dokładne informacje o sposobie użycia programu w konkretnym systemie.

Fetchmail, czyli coś dla "frikowców"

Wielokrotnie zaznaczałem w poprzednich tekstach, że opisywane możliwości manipulowania pocztą dotyczą tylko pełnych kont Unixowych z dostępem do shella. Cóż jednak mają począć posiadacze tak popularnych obecnie kont pocztowych POP3? Tysiące użytkowników korzystają z kont tego typu - zarówno bezpłatnych, na darmowych serwerach, jak i komercyjnych. Czy możliwości autoforwardu, filtrowania poczty na serwerze, automatycznych odpowiedzi itp. są przed nimi zamknięte?

Teoretycznie oczywiście nic nie stoi na przeszkodzie korzystaniu z tego typu udogodnień także na kontach POP3. W końcu serwer obsługujący pocztę jest przeważnie serwerem Unixowym: jeżeli administrator zainstaluje na serwerze odpowiednie programy i udostępni jakiś mechanizm, za pomocą którego użytkownik może nimi zarządzać - np. za pośrednictwem strony WWW - to będzie możliwe ich wykorzystanie, przynajmniej w ograniczonym zakresie. Na niektórych serwerach kont pocztowych możliwe jest skonfigurowanie autoforwardu; gdzie indziej zrealizowanie autorespondera (ta możliwość najczęściej dotyczy najdroższych wariantów kont "biznesowych"). Często jednak nie ma nic.

Niestety, trzeba zdawać sobie sprawę z tego, iż każde konto typu "tylko do poczty/WWW", nawet takie, które w nazwie ma "Business" i "Professional" i kosztuje grube pieniądze, jeżeli nie daje dostępu do shella, jest w Internecie po prostu produktem niepełnowartościowym. Konto takie jest niczym demonstracyjna wersja programu - pozwala zapoznać się z jego działaniem i zrobić parę prostych rzeczy, ale nie pozwala w pełni "rozwinąć skrzydeł" i wykorzystać wszystkich możliwości oferowanych przez program. Niektórym oczywiście taka wersja demonstracyjna może w pełni wystarczać - ale jeżeli ktoś ma potrzeby wykraczające poza jej możliwości, musi kupić wersję pełną.

Dla użytkowników kont POP3 wypływa z tego niezbyt pomyślny wniosek: trzeba będzie jednak założyć sobie konto z shellem. Jest jednak także i dobra wiadomość: wystarczy mieć tylko jedno konto shellowe, a z udostępnianych przez nie możliwości przetwarzania poczty będzie można skorzystać także na wszystkich innych posiadanych kontach typu POP3! Tak więc nawet użytkownik darmowych serwerów typu "friko" czy "free" może skorzystać z procmaila, vacation itp. - jeżeli ma oprócz tego gdzieś konto z dostępem do shella.

Ta "magiczna sztuczka" możliwa jest dzięki programowi o nazwie fetchmail. Pomysł programu jest banalnie prosty: fetchmail po prostu, korzystając z tego samego protokołu POP3, co każdy klient poczty na PC, "ściąga" pocztę z konta pocztowego na innym serwerze - a właściwie z dowolnej liczby takich kont - na lokalne konto Unixowe, gdzie można już do niej zastosować wszystkie mechanizmy typu .forward, procmail itp. w sposób identyczny, jak do poczty przysłanej bezpośrednio na to konto. Efekt jest podobny, jakbyśmy mieli ustawiony autoforward z konta POP3 na konto Unixowe - tylko że fetchmail nie wymaga ustawiania niczego po stronie serwera, z którego będziemy "ściągać" pocztę, daje się zatem zastosować także wtedy (a nawet przede wszystkim wtedy), gdy serwer ten nie umożliwia skonfigurowania autoforwardu.

Najprostszy sposób wywołania programu polega po prostu na wpisaniu w wierszu poleceń shella polecenia "fetchmail". Program połączy się z serwerem lub serwerami zadeklarowanymi w pliku konfiguracyjnym, "ściągnie" listy z odpowiednich kont i zakończy pracę. Możemy teraz uruchomić dowolny czytnik poczty, np. elm lub pine i przeczytać otrzymane e-maile.

Do uruchomienia fetchmaila potrzebny jest - jak już wspomniano powyżej - plik konfiguracyjny. Plik taki trzeba utworzyć przed pierwszym uruchomieniem programu. W pakiecie fetchmaila znajduje się działający w środowisku graficznym program fetchmailconf, za pomocą którego można stworzyć plik konfiguracyjny poprzez "wyklikanie" odpowiednich opcji myszą. Jest on jednak przydatny praktycznie tylko wówczas, gdy Unixa (np. Linuxa) mamy na swoim domowym komputerze - łącząc się z kontem na "obcym" serwerze nie mamy z reguły możliwości pracy w trybie graficznym (chyba że łączymy się z innego komputera Unixowego lub posiadamy oprogramowanie tzw. X-serwera dla Windows).

Plik konfiguracyjny można jednak bez trudu utworzyć "ręcznie", za pomocą dowolnego edytora (np. joe): jest to - jak zresztą zwykle w oprogramowaniu Unixowym - zwykły plik tekstowy ASCII, który może zawierać w najprostszej postaci np. taką treść:

     poll "free.polbox.pl"
     username "kowalski"
     password "jasio"
Jak widać, plik zawiera takie same dane, które musimy wpisać w każdym programie pocztowym dla "ściągnięcia" poczty z konta POP3. Pozycja rozpoczynająca się słowem "poll" zawiera adres serwera, z którego będziemy pobierać pocztę: po niej występują nazwa konta na tym serwerze i hasło. Obydwa te wiersze można pominąć; jeżeli pominiemy hasło, fetchmail będzie pytał o nie przy każdym uruchomieniu, jeżeli natomiast pominiemy nazwę użytkownika - program przyjmie taką samą nazwę, jak nazwa konta, z którego go uruchamiamy. Jeżeli chcemy pozostawiać pocztę na serwerze po jej "ściągnięciu", możemy dopisać do powyższego pliku jeszcze linijkę zawierającą słowo "keep".

Bloków takich, jak powyższy, może występować w pliku konfiguracyjnym wiele kolejno po sobie - każdy z nich dotyczył będzie następnego konta, z którego fetchmail ma czytać pocztę. Program uruchomiony bez parametrów "ściągnie" pocztę ze wszystkich zdefiniowanych kont; podając w wywołaniu programu w sposób jawny adresy serwerów można wybrać tylko niektóre spośród nich.

Plik konfiguracyjny fetchmaila nosi nazwę .fetchmailrc i powinien znajdować się w katalogu macierzystym użytkownika. Ze względu na to, iż w pliku tym znajdują się nasze hasła, inni użytkownicy danego systemu Unixowego nie powinni mieć dostępu do odczytu tego pliku. Jeżeli fetchmail wykryje, że zachodzi taka sytuacja (tzn. plik .fetchmailrc jest dostępny do czytania dla innych użytkowników), nie pozwoli się uruchomić, dopóki nie ustawimy właściwych praw dostępu.

Aby sprawdzić, jakie prawa dostępu ma plik .fetchmailrc, wpisujemy po jego utworzeniu w wierszu poleceń komendę:

     ls -l .fetchmailrc
co powinno wyświetlić wiersz podobny do poniższego:

     -rw-------   1 raj      users         65 Jan 28 20:30 .fetchmailrc
Jeżeli na początku tego wiersza znajduje się taka kombinacja znaków, jak powyżej - tzn. "-rw-------" - prawa dostępu do pliku .fetchmailrc są prawidłowe. Wystąpienie jakiejkolwiek dodatkowej literki w tym polu oznacza, że aktualne uprawnienia do tego pliku są zbyt szerokie; trzeba je skorygować wydając komendę:

     chmod 600 .fetchmailrc
co powinno nadać plikowi właściwe uprawnienia.

Ściąganie automatyczne

Ręczne uruchamianie fetchmaila to jednak zbyt mało, aby korzystać ze wszystkich możliwości przetwarzania poczty. Np. program vacation powinien sam odpowiadać na listy podczas naszej nieobecności - jest to w końcu istotą jego działania! Kilka akapitów wyżej porównałem działanie fetchmaila do autoforwardu z konta POP3 na konto Unixowe. Jednak w przypadku prawdziwego autoforwardu przesłanie poczty z jednego serwera na drugi odbywa się automatycznie w chwili przyjścia listu (i vacation może od razu na niego odpowiedzieć) - tu natomiast jest ono inicjowane "ręcznie", przez uruchomienie programu fetchmail. Aby móc sensownie korzystać z takich możliwości, jak np. vacation, czy przesyłanie poczty na telefon komórkowy, musimy więc znaleźć jakiś sposób na regularne, automatyczne uruchamianie fetchmaila co pewien czas bez naszej interwencji.

Twórcy fetchmaila pomyśleli oczywiście o takim jego zastosowaniu: program można uruchomić w trybie tzw. demona, w którym działa on w tle i w określonych odstępach czasu sam łączy się z wymienionymi w pliku konfiguracyjnym serwerami dla "ściągnięcia" poczty. Ustawienie odpowiednio krótkiego (np. co godzinę) odstępu między kolejnymi połączeniami powoduje, że pobieranie poczty tak uruchomionym fetchmailem zaczyna przypominać rzeczywisty autoforward - listy "same" w regularnych odstępach czasu przesyłane są z konta POP3 na konto Unixowe.

Aby uruchomić program w ten sposób, należy podać w jego wywołaniu parametr -d, po którym następuje czas (w sekundach) pomiędzy kolejnymi połączeniami. Przykładowo, aby pobierać pocztę co godzinę, wydajemy komendę:

     fetchmail -d 3600
Program uruchomiony w ten sposób będzie pracował "w nieskończoność" (także po naszym wylogowaniu się z systemu), aż do zatrzymania go przez nas samych bądź administratora systemu, albo w wyniku wyłączenia serwera. Aby zatrzymać fetchmaila działającego w trybie demona, należy wydać komendę

     fetchmail --quit
Jeżeli fetchmaila pracującego w tym trybie używamy do komunikacji z serwerami, z którymi połączenie często zawodzi, praktyczne może być utworzenie pliku, w którym program zapisywał będzie raport z wszystkich swoich działań. Plik taki tworzymy podając w wywołaniu programu dodatkowo parametr -L (duża litera!), po którym podajemy nazwę pliku, np.

     fetchmail -d 3600 -L raport.txt
W dowolnym późniejszym czasie logując się na swoje konto możemy przeglądać zawartość pliku raport.txt i kontrolować w ten sposób działanie programu.

Inną możliwością regularnego uruchamiania fetchmaila - przydatną zwłaszcza, gdy chcemy to robić w rzadszych odstępach, np. raz dziennie - jest uruchamianie go za pomocą zawartego w każdym Unixie systemowego mechanizmu cron, służącego do automatycznego uruchamiania dowolnych programów w ustalonych wcześniej terminach. Jeżeli mamy możliwość korzystania z crona (niektórzy administratorzy niechętnie udostępniają crona użytkownikom), możemy wpisać fetchmaila do tablicy zadań, które system ma automatycznie wykonywać. W tym celu wpiszmy polecenie

     crontab -e
Polecenie to powinno wywołać edytor, w którym będziemy mogli dokonać modyfikacji naszej tablicy zadań okresowych (o ile dotąd nie korzystaliśmy z crona, tablica ta powinna być pusta). Obowiązuje tu analogiczna uwaga na temat edytora, jak poczyniona w pierwszej części artykułu przy okazji opisu programu vacation - jeżeli okaże się, że edytorem wywoływanym przez polecenie crontab jest vi, należy ustawić sobie inny edytor systemowy poleceniem

     EDITOR=program ; export EDITOR
w shellu Bourne'a, natomiast

     setenv EDITOR program
w shellu C, gdzie "program" w obydwu przypadkach jest nazwą edytora, z którego chcemy korzystać (np. joe).

Każdy wiersz pliku, który tworzymy poleceniem crontab -e, powinien mieć następujący format:

     minuta godzina dzień miesiąc dzieńtygodnia komenda
Komenda jest dowolną komendą Unixa, którą będziemy chcieli uruchamiać o wskazanej porze (można oczywiście umieścić w pliku crontab wiele różnych komend, uruchamianych w różnym czasie). Minutę, godzinę, dzień i miesiąc podaje się w postaci ogólnie stosowanych oznaczeń liczbowych. Dzień tygodnia również podaje się w postaci liczby od 0 do 6, gdzie 0 oznacza niedzielę. Każda z pięciu pozycji określających czas może być także zastąpiona gwiazdką, co oznacza, że wartość danego parametru jest nieistotna - wskazana na końcu wiersza komenda ma się wykonywać o każdej godzinie, każdego dnia itp.

Aby np. uruchamiać fetchmaila codziennie o godzinie 9:00 rano, wpiszemy do pliku crontab następujący wiersz:

     0 9 * * * fetchmail
(w zależności od konfiguracji systemu, przy uruchamianiu programu z crona może być potrzebne podanie zamiast samej nazwy - pełnej ścieżki dostępu, a więc np. /usr/local/bin/fetchmail). Poniższy zaś wiersz spowoduje uruchamianie fetchmaila dwa razy w tygodniu, o 18:30 w poniedziałki i czwartki:

     30 18 * * 1,4 fetchmail
W tym przypadku nie jest potrzebne podawanie żadnych dodatkowych parametrów do fetchmaila, gdyż program uruchamiany jest w sposób analogiczny, jakbyśmy uruchomili go ręcznie. Raport z jego działania otrzymamy... e-mailem na nasze konto (jak w przypadku każdej komendy uruchamianej z crona) - jeżeli nie jest nam potrzebny, możemy go rzecz jasna odfiltrować i skasować, np. za pomocą procmaila. Możemy też wyłączyć wypisywanie komunikatów przez program (pozostaną jedynie komunikaty błędów) dodając do wywołania fetchmaila opcję -s - wówczas po pomyślnym "ściągnięciu" poczty nie zostanie wyprodukowany żaden raport.

Fetchmail ma oczywiście znacznie więcej możliwości, niż opisano powyżej. Między innymi uruchamiany z konta administratora systemu może służyć do "ściągania" poczty dla wielu użytkowników równocześnie i rozdzielania jej do odpowiednich lokalnych skrzynek. Potrafi też obsługiwać inne protokoły pobierania poczty z serwera (POP2, APOP, IMAP) rozpoznając i wybierając odpowiedni protokół automatycznie. W znakomitej większości typowych zastosowań pojedynczemu użytkownikowi całkowicie wystarczą jednak możliwości opisane tutaj.

Możliwe jest samodzielne zainstalowanie fetchmaila, w sposób analogiczny do przedstawionego w artykule na temat programu wget w numerze 2/99 MI, jeżeli nie ma go na komputerze, na którym mamy konto. Fetchmail ma swoją stronę macierzystą w Internecie pod adresem http://www.tuxedo.org/~esr/fetchmail/ - można pobrać go albo stamtąd, albo z archiwum plików SunSITE: ftp://sunsite.icm.edu.pl/pub/Linux/sunsite/system/mail/pop/!INDEX.html. Aktualna (w chwili pisania tekstu) wersja programu to 4.7.9, stąd też plik zawierający wersję źródłową programu nosi nazwę fetchmail-4.7.9.tar.gz (jest też dostępna skompilowana już wersja dla systemu Linux w postaci pliku .rpm). Rozpakowanie pliku i kompilację programu wykonujemy tak, jak to opisano w artykule o wget'cie; powstały gotowy program fetchmail kopiujemy do swojego katalogu macierzystego.

Konto, ale skąd?

I oto dochodzimy do podstawowego problemu związanego z wykorzystaniem opisywanych w tym cyklu artykułów możliwości: trzeba sobie założyć konto shellowe, ale gdzie? Pracownicy instytucji posiadających własne serwery Unixowe podłączone do Internetu (czy np. na uczelni - studenci) na ogół nie będą mieli problemu z uzyskaniem konta w swoim miejscu pracy czy nauki. Konto shellowe można też założyć - rzecz jasna odpłatnie - u niemal każdego providera Internetu. Jeżeli mamy już założone u jakiegoś providera konto POP3, bardzo prawdopodobne jest, że za niewielką dopłatą możliwe będzie uzyskanie dostępu do shella.

Tym, co najatrakcyjniejsze dla przeciętnego użytkownika Internetu, są jednak konta darmowe. Znaleźć w Internecie serwer oferujący darmowe konta shellowe - w przeciwieństwie do kont POP3 - nie jest łatwo. Przyczyną są przede wszystkim względy bezpieczeństwa: serwer z darmowym, a więc dostępnym praktycznie anonimowo dla każdego shellem to wręcz wymarzone środowisko dla hackerów i wszelkiego rodzaju Internetowych szkodników, którzy mogą stamtąd włamywać się i atakować inne systemy. Z tych też powodów serwery oferujące darmowe konta z dostępem do shella często po krótkim okresie działalności są likwidowane; choć w Internecie znaleźć można wiele wykazów takich serwerów, większość znajdujących się na nich adresów jest nieaktualna - serwera albo w ogóle nie ma, albo nie można już na nim zakładać nowych kont. Po przejrzeniu wielu takich wykazów zdołałem odnaleźć zaledwie pięć serwerów, które obecnie rzeczywiście umożliwiają zakładanie darmowych kont z shellem.

Zacznijmy od serwerów zagranicznych. SDF (sdf.lonestar.org) mieni się być najstarszym działającym do dziś systemem udostępniającym publiczne konta Unixowe - uruchomiony został w 1987 r.! Jego "konkurentami" w zakresie darmowych kont są Arbornet (m-net.arbornet.org) i Grex (cyberspace.org). Zakładanie konta na każdym z tych serwerów odbywa się w sesji telnetowej, uruchamianej automatycznie przez kliknięcie odpowiedniego odsyłacza na stronie WWW (można oczywiście od razu zalogować się telnetem na serwer, bez "przechodzenia" przez WWW). Jedynie na serwerze Grex istnieje możliwość założenia konta także bezpośrednio z poziomu strony, poprzez wypełnienie odpowiedniego formularza. Oprócz standardowych danych personalnych, program zakładający konta pyta o szereg informacji technicznych przydatnych do właściwego skonfigurowania zakładanego konta - takich jak np. wybór domyślnego shella i edytora, których będziemy chcieli używać (wszystkie te parametry można będzie w dowolnym późniejszym czasie zmienić, jeżeli nasz początkowy wybór nie będzie nam odpowiadać). Najbardziej złożoną procedurę zakładania nowego konta, wzorowaną na stosowanej w BBS-ach, ma Arbornet; bo też system ten jest w istocie właśnie BBS-em. Przy pierwszym zalogowaniu na nowo utworzone konto wita nas klasyczne, charakterystyczne dla BBS-ów menu; można jednak je wyłączyć i przejść do normalnego shella Unixowego.

Darmowe konta na wszystkich trzech powyższych serwerach mają - ze względu na wspomniane wcześniej zagrożenie wykorzystywaniem kont do działalności hackerskiej - szereg ograniczeń. Zablokowane są połączenia wychodzące do innych komputerów w Internecie (a więc nie zalogujemy się na inny serwer przez telnet - ale też znikąd nie "ściągniemy" poczty fetchmailem...), nie można też po wylogowaniu się pozostawiać żadnych procesów działających w tle; niedostępny jest rzecz jasna także cron. (Większość z tych ograniczeń zostanie zniesiona, jeżeli zdecydujemy się zapłacić za konto.) Możemy natomiast do woli - co w tym cyklu artykułów najbardziej nas interesuje - korzystać z procmaila, vacation oraz wszelkich innych możliwości pliku .forward (na serwerze Grex są aktualnie problemy techniczne z procmailem, związane z nietypowym formatem skrzynek pocztowych - administratorzy zapowiadają ich rychłe usunięcie).

Z uwagi na te ograniczenia, jak też i na stosunkowo duże opóźnienia w transmisji z amerykańskimi serwerami, dające się mocno we znaki przy pracy interakcyjnej, warto skierować swoją uwagę raczej w stronę polskich serwerów. Darmowe konta shellowe można założyć pod adresami www.xox.pl * oraz www.free.net.pl. Pierwszy z serwerów ze względów bezpieczeństwa ma wyłączoną usługę telnet - skorzystanie z założonego konta wymaga użycia programu ssh, zapewniającego szyfrowanie połączenia. Odpowiedni klient ssh dostępny jest do pobrania na stronie WWW. Z drugim serwerem można połączyć się na obydwa sposoby - zarówno "zwyczajnie" przez telnet, jak i w sposób bezpieczny przez ssh.

Obydwa te serwery dają użytkownikom znacznie więcej swobody, niż amerykańskie. Nie ograniczają połączeń wychodzących; możliwe jest korzystanie z takich programów jak fetchmail czy (trochę z innej beczki) wget. Na serwerze xox.pl niedozwolone jest pozostawianie procesów pracujących w tle po wylogowaniu; nie uruchomimy zatem tam fetchmaila w trybie demona, ani nie pozostawimy wgeta, aby "ściągał" pliki, gdy jesteśmy off-line. Zakazu takiego nie ma na serwerze free.net.pl; wolno tam pozostawiać programy pracujące w tle, aczkolwiek administratorzy rezerwują sobie prawo do przerwania ich w każdej chwili, gdyby uznali, że przeszkadzają one w prawidłowej pracy systemu. Ten ostatni serwer nie blokuje też użytkownikom możliwości kompilowania i uruchamiania swoich własnych programów ** - na serwerze xox.pl jest to niemożliwe. Jedynym ograniczeniem kont na serwerze free.net.pl jest więc w zasadzie tylko brak dostępu do crona - ale ograniczenie to występuje również i na wielu kontach komercyjnych... Warto zatem polecić ten serwer - i równocześnie zaapelować do wszystkich tych, którzy będą zakładać sobie na nim konta, o rozsądek. Nie nadużywajcie swoich kont do "niecnych" celów: skończyć się to może tylko tak, że albo możliwości zostaną drastycznie ograniczone, podobnie jak na serwerach amerykańskich, albo serwer zniknie całkowicie. Ani jeden, ani drugi wariant nie jest dobry dla nikogo...

Na zakończenie chciałem wspomnieć o pewnym problemie z działaniem procmaila, występującym na serwerze xox.pl. Otóż skrzynki pocztowe użytkowników tego serwera zrealizowane są w tzw. formacie Maildir, co sprowadza się z grubsza do tego, że zamiast trzymać całą pocztę użytkownika w jednym dużym pliku znajdującym się w "systemowym" obszarze dysku (typowo w katalogu /var/mail lub /var/spool/mail), każdy list przechowywany jest jako oddzielny plik w podkatalogu o nazwie Maildir w macierzystym katalogu użytkownika. Niestety, zainstalowany na tym serwerze procmail nie jest całkowicie zgodny z tym formatem. Problem polega na tym, że gdy w wyniku działania procmaila list miałby być pozostawiony w domyślnej skrzynce (bo np. nie pasował do żadnej reguły w pliku .procmailrc, albo odpowiednia reguła zawierała znacznik "c"), procmail nie potrafi go tam zapisać. W efekcie list wraca do kolejki pocztowej serwera, skąd za chwilę system transportu poczty znów próbuje go dostarczyć do użytkownika, procmail znów nie może zapisać listu do skrzynki... i tak w kółko. Jeżeli wcześniej w pliku .procmailrc dokonujemy np. przesłania listu na telefon komórkowy, będziemy otrzymywać niekończące się serie wiadomości dotyczących tego samego listu, podczas gdy sam list nie pojawi się w naszej skrzynce pocztowej!

Zaradzić temu problemowi można w prosty sposób - wystarczy na samym końcu pliku .procmailrc dodać następującą regułę:

     :0
     Maildir/cur
Reguła ta nie zawiera żadnego warunku - każdy list, który "dotrwał" jeszcze do tego miejsca pliku .procmailrc, jest bezwarunkowo zapisywany do odpowiedniego podkatalogu katalogu Maildir, w którym przechowywana jest zawartość domyślnej skrzynki pocztowej. ***

I to już chyba wszystkie "sztuczki z pocztą" - mam nadzieję, że pomogą one naszym Czytelnikom w jak najefektywniejszym wykorzystaniu tego naprawdę rewelacyjnego środka łączności, jakim jest e-mail.

* Zakładanie nowych kont na serwerze xox.pl jest obecnie wstrzymane.
** Z uwagi na niestety mające miejsce nadużycia kont na serwerze free.net.pl możliwość uruchamiania własnych programów została tam również zablokowana.
*** Analogiczny problem występuje od niedawna również na serwerze free.net.pl; tam z kolei trzeba dodać do pliku .procmailrc regułę

     :0:
     Mailbox

Jarosław Rafa 1999. Tekst udostępniony na licencji Creative Commons (uznanie autorstwa - użycie niekomercyjne - bez utworów zależnych). Kliknij tutaj, aby dowiedzieć się, co to oznacza i co możesz z tym tekstem zrobić. W razie jakichkolwiek wątpliwości licencyjnych bądź w celu uzyskania zgody na rozpowszechnianie wykraczające poza warunki licencji proszę o kontakt e-mailem: raj@ap.krakow.pl.

Wersja HTML opracowana 15.06.99.

Powrót do wykazu artykułów o Internecie Statystyka