path: root/zmailer-pl.txt

ZMailer - instalacja i konfiguracja
(C) 1998 Jan Rychter

Niniejszy artykuł można kopiować i rozprowadzać wyłącznie w całości na
zasadach licencji GNU w wersji 2 lub dowolnej późniejszej wersji.

Dla "Magazynu Linux/UNIX", wrzesień/98
$Id$



ZMailer - co to jest ?


ZMailer jest szybkim i bezpiecznym MTA (Mail Transfer Agent) dla
systemów UNIX. Zajmuje się rozsyłaniem i przekazywaniem poczty
elektronicznej, otrzymanej od programów MUA (Mail User Agent) takich jak
mutt, pine, elm, od procesorów list dyskusyjnych (majordomo, petidomo,
listserv) lub od innych maszyn w sieci. Odgrywa w systemie rolę podobną
do powszechnie znanego i stosowanego programu sendmail, różni się jednak
od niego znacznie na korzyść jeżeli chodzi o bezpieczeństwo i
wydajność. Warto poznać ten program, chociażby dlatego, że można w ten
sposób zyskać zupełnie inne spojrzenie na przetwarzanie poczty
elektronicznej pod UNIXem.


Po co ? Spojrzenie praktyka.


Narzuca się pytanie: po co właściwie w ogóle interesować się innym MTA
niż sendmail, skoro ten jest standardowo instalowany w większości
Linuxów ? Odpowiedzi może być wiele. Najlepszym powodem jest różnica w
wydajności. Sendmail ma poważne ograniczenia jeżeli chodzi o prędkość
przetwarzania poczty, wynikające z jego architektury. Eksperci znający
się doskonale na konfiguracji sendmaila potrafią obejść do pewnego
stopnia niektóre z tych ograniczeń, jest to jednak trudne, niewygodne i
nadal nie rozwiązuje w pełni problemu. ZMailer za to od początku był
projektowany ze specjalnym naciskiem na wydajność. Jest tak pomyślany,
by jak najmniej obciążając maszynę na której działa, przekazać jak
najwięcej listów w jak najkrótszym czasie.

Dobrym praktycznym przykładem instalacji, gdzie sendmail się nie
sprawdził, a ZMailer rozwiązał problemy, jest system dystrybucji list
dyskusyjnych z maszyny vger.rutgers.edu (między innymi lista
linux-kernel). Początkowo na vger działał sendmail, bezpośrednio
rozsyłający nowe listy do wszystkich zapisanych na listy dyskusyjne. Po
przekroczeniu pewnej ilości osób korzystających z list, zaczęły się
pojawiać problemy z rozsyłaniem. Opóźnienia zaczęły sięgać tygodnia.
Wprowadzony został nieco ulepszony system tzw. "mail exploders". Polega
on na tym, że vger.rutgers.edu część pracy przekazuje innym maszynom:
adresami z domeny .com zajmuje się inny komputer niż adresami z
.net. Sam vger.rutgers.edu wie, że wszystkie listy dla domen .com ma
posłać jednemu "exploderowi". Zajmuje się też rozesłaniem wszystkich
listów dla których nie ma zdefiniowanego "explodera". System ten nieco
poprawił sytuację, jednak obciążenie vger.rutgers.edu było nadal zbyt
duże. Dopiero wymiana programu sendmail na ZMailer pomogła - i to na
tyle dobrze, że do dziś system działa bez problemów.

ZMailer jest też stosowany na wielu innych maszynach mających do
przetworzenia olbrzymie ilości poczty -- dobrymi przykładami są
np. ftp.funet.fi albo SunSITE.icm.edu.pl.


Czy to nie jest to samo co sendmail ?


ZMailer od sendmaila różni się diametralnie. Jedyne co pozostaje
podobne, to rola jaką oba programy spełniają w systemie. Największą
praktyczną różnicą pomiędzy nimi jest sposób przetwarzania kolejek i
listów przeznaczonych dla wielu adresatów. Sendmail otrzymawszy do
rozesłania list zaadresowany do kilkuset osób z całego świata (częste w
przypadku list dyskusyjnych) zajmie się przetwarzaniem go
sekwencyjnie. Najpierw spróbuje pierwszego adresu, potem
następnych. Jeżeli któryś okaże się nieprawidłowy, spowoduje opóźnienie
i wszystkie następne będą musiały poczekać. W praktyce opóźnienie
pomiędzy otrzymaniem listu przez pierwszego adresata a ostatniego
potrafi sięgać paru dni (!).

Dla odróżnienia, ZMailer najpierw analizuje nagłówki listu i rozkłada go
na wiele kolejek przetwarzania (według zdefiniowanych przy konfiguracji
zasad). Oznacza to, że list zaadresowany do kilkuset osób zostanie
rozdzielony na od kilku do kilkudziesięciu kanałów, z których każdy
będzie przetwarzany sekwencyjnie. Dla wyżej wspomnianego skrajnego
przypadku (gdy sendmailowi rozesłanie listu zajmowało kilka dni) po
instalacji ZMailera czas ten skrócił się do kilku minut.


Czy tego samego nie potrafi QMail ?


QMail jest w wielu aspektach podobny do ZMailera. Podobnie jak on został
zaprojektowany całkowicie od nowa, czerpiąc z doświadczeń innych. Jest
również bardzo nastawiony na wydajność -- po bezpieczeństwie jest ona
następną najbardziej reklamowaną zaletą QMaila. Trudno jest obiektywnie
stwierdzić, czy którykolwiek z nich jest lepszy pod względem
technicznym. Prawdopodobnie w realnej pracy różnice będą
niewielkie. QMail jest za to nielubiany przez wielu z powodu dość
restrykcyjnej licencji oraz nieco dziwnego podejścia autora programu do
specyfikacji RFC (Internetowych Request For Comments, czyli
półformalnych standardów obowiązujących w sieci). QMail implementuje z
RFC to, co autor uznał za stosowne -- resztę odrzuca. Powoduje to, że
czasem zachowuje się w sposób inny od wszystkich innych programów MTA i
niekoniecznie stosuje się do wszystkich standardów.


Architektura


ZMailer nie jest programem monolitycznym. Składa się z wielu procesów,
współpracujących ze sobą. Trzy z nich są najważniejsze i pracują w
systemie praktycznie cały czas:

  smtpserver -- zajmuje się słuchaniem na porcie TCP 25 i przyjmowaniem
  przychodzących tą drogą listów. Potrafi też wstępnie filtrować pocztę,
  odrzucając tą niechcianą (spam, reklamy). Ponieważ odrzuca pocztę
  jeszcze na etapie przyjmowania jej, listy takie nie zajmują ani miejsca
  na dysku ani pasma sieciowego.

  router -- przetwarza nagłówki poczty. Pobiera pocztę którą przyjął
  smtpserver, bądź tą którą dostał do wysłania lokalnie od jakiegoś MUA,
  następnie przegląda i ewentualnie przepisuje (modyfikuje) nagłówki,
  sprawdza istnienie adresów w DNS, rozwija aliasy oraz tworzy
  odpowiedni plik kontrolny. Routerów w systemie może być kilka (z
  reguły cztery), dla przyspieszenia przetwarzania poczty i uniknięcia
  opóźnień wprowadzanych przez DNS.

  scheduler -- zleca rozsyłanie poczty. Czyta pliki kontrolne stworzone
  przez router, rozdziela pocztę na kanały przetwarzania (kolejki), oraz w
  odpowiednim czasie uruchamia programy TA celem dostarczenia poczty.

Ponadto, istnieje pewna liczba "transfer agents" (TA) które zajmują się
dostarczaniem poczty różnymi protokołami. Przykładami są: smtp
(dostarcza pocztę protokołem SMTP), mailbox (dostarcza do lokalnych
skrzynek pocztowych), sm (konfigurowalny osobno TA kompatybilny z
sendmailem pozwalający np. na tworzenie bramek mail2news lub spięcie z
programem Cyrus IMAP), errormail (zajmuje się dostarczeniem komunikatów
o błędach, jest bardziej wrażliwy na możliwe problemy i pętle pocztowe)
itp.

Warto zauważyć, że w powyższej liście jedynym programem który musi być
uruchomiony z prawami roota (uid 0) jest smtpserver -- musi on
nasłuchiwać na porcie 25, a to wymaga praw roota. Cała reszta systemu
może pracować np. jako użytkownik nobody i w naprawdę bezpiecznych
instalacjach tak właśnie się to konfiguruje. Znakomicie podnosi to
bezpieczeństwo całego systemu, gdyż ogranicza się możliwości włamania do
jednego programu, który jest dokładnie pod względem bezpieczeństwa
zbadany. Ponadto, warto zauważyć, że smtpserver nie musi być wykonywalny
przez lokalnych użytkowników. Odcina to kolejną klasę włamań poprzez
uruchamianie programów "setuid root" z nieprawidłowymi opcjami. Między
innymi właśnie dlatego określa się ZMailer jako program bezpieczny.

Dla odróżnienia sendmail zawiera się w jednym procesie (programie),
który robi wszystko, zależnie od opcji z jakimi się go
uruchomi. Musi on być uruchamiany z prawami roota (uid 0) z tych samych
powodów co smtpserver w ZMailerze. W tym przypadku jednak możliwości na
wykorzystanie ewentualnych dziur jest znacznie więcej -- szczególnie że
sendmail jest programem uruchamianym przez lokalnych użytkowników w
systemie i bardzo trudno jest tego uniknąć.


... a konkretniej ?


Obszar roboczy ZMailera (spool, postoffice) podzielony jest na kilka
podkatalogów. Najważniejsze z nich to:

  public/ -- w tym katalogu użytkownicy mogą tworzyć pocztę do wysłania.
  Z reguły zajmuje się tym program MUA użytkownika uruchamiając program
  /usr/lib/sendmail, który jest podstawioną przez ZMailera emulacją
  sendmaila.

  router/ -- do tego katalogu poprzez operację rename() przerzucana jest
  (atomicznie) poczta z katalogu public. Poczta nigdy nie jest tu
  tworzona, aby uniknąć sytuacji w której proces router zauważyłby i
  zaczął przetwarzać list, który nie został jeszcze do końca utworzony
  (skopiowany).

  queue/, transport/ -- katalogi robocze służące do rozsyłania poczty. Gdy
  router zakończy przetwarzanie nagłówków poczty, przenosi (również
  używając rename()) list z katalogu router/ do queue/, zaś w transport/
  tworzy plik kontrolny dla tego listu. Katalog transport/ ogląda proces
  scheduler, zlecając rozesłanie listów w odpowiednim czasie.

Istnieją też katalogi freezer/ i postman/, służą one do specjalnych
celów. W katalogu freezer/ pojawia się poczta którą smtpserver
podejrzewa o bycie niepożądaną (element konfiguracji
anty-spammingowych). Zatrzymana jest do obejrzenia i ew. posłania
dalej. W katalogu postman/ zapisywane są listy, które absolutnie nie
mogą być dostarczone z powodu nadmiernych ilości błędów, nie mogą też
być zwrócone do nadawcy (przypadki raczej patologiczne).


Instalacja


Oprogramowanie znaleźć można w katalogu
ftp://SunSITE.icm.edu.pl/pub/unix/mail/zmailer/src/. W chwili pisania
tego artykułu najnowszą wersją ZMailera była wersja 2.99.50-s5. Być może
gdy pismo ukaże się w druku, będzie już od dawna oczekiwana wersja
3.0. Oprogramowanie należy rozpakować np. w /usr/src i wejść do
utworzonego podkatalogu. Warto też w tym momencie zerknąć na
dokumentację dostępną pod adresem http://www.zmailer.org/.

ZMailer przygotowywany jest do kompilacji przy użyciu programu GNU
autoconf, więc w zasadzie wystarczy napisać ./configure; make aby go
skompilować. Warto jednak przyjrzeć się niektórym dostępnym opcjom
configure:

--prefix=/katalog -- umiejscawia drzewo katalogów ZMailera. Pod tym
katalogiem zostanie utworzonych kilka innych. Znajdą się tam zarówno
programy wykonywalne, jak i pliki konfiguracyjne ZMailera. Polecam
ustawienie --prefix=/local/lib/mail (gdzie /local jest linkiem do
/usr/local).

--with-mailbox=/katalog -- gdzie znajdują się skrzynki E-pocztowe
użytkowników do których ma być dostarczana lokalna poczta. Z reguły w
Linuxie jest to katalog /var/spool/mail.

--with-postoffice=/katalog -- gdzie ZMailer ma przetwarzać pocztę
(tzw. spool). Jest to katalog, gdzie utworzone będą podkatalogi: public,
router, transport, queue. Standardowo zaleca się /var/spool/postoffice.

--with-logdir=/katalog -- gdzie mają być umieszczane logi ZMailera.

--with-selfaddresses= -- adresy na których smtpserver ma nasłuchiwać na
porcie 25. Podawane w formacie [10.2.1.1],[127.0.0.1].

--with-sendmailpath= -- gdzie ma zostać umieszczony podmieniony program
sendmail (emulujący lokalnie prawdziwego sendmaila i służący do
wysyłania poczty).

--with-ipv6 -- włączenie wsparcia dla IP w wersji szóstej.

Warto zwrócić uwagę na poprawne wpisanie wszystkich adresów IP na
których smtpserver ma słuchać. W przypadku komputera z jednym adresem
nie stanowi to problemu, jednak jeśli maszyna ma kilka adresów, należy
wpisać je wszystkie.

Po napisaniu ./configure z odpowiednimi opcjami ZMailer powinien być
gotowy do kompilacji. Samą kompilację uruchamia się komendą make,
zainstalować program można przez make install. Warto zwrócić uwagę, czy
podczas instalacji nie pracuje proces sendmail. Najlepiej wcześniej po
prostu usunąć sendmail z systemu, nie będzie już do niczego potrzebny.


Ciąg dalszy: konfiguracja -- w następnym odcinku.

[ stopka:

RG Studio zajmuje się doradztwem Linux/UNIX, instalacjami systemów,
utrzymaniem i zabezpieczaniem istniejących instalacji, oraz sprzedażą
specjalizowanego sprzętu związanego z Linuxem: kart frame-relay Sangoma
Technologies i Emerging Technologies, mikroserwerów Cobalt Qube firmy
Cobalt Networks, płyt głównych i procesorów Samsung Alpha, a także kart
wieloportowych Cyclades i sprzętu Gigabit Ethernet firmy Packet
Engines. Kontakt: E-poczta: info@rgstudio.com.pl, WWW:
http://www.rgstudio.com.pl/, Adres: RG Studio, Limanowskiego 23, 02-934
Warszawa, Tel./Fax.: (22) 6516638.

Z autorem można skontaktować się pod adresem: Jan Rychter
<jwr@rgstudio.com.pl>

]



ZMailer - instalacja i konfiguracja, część 2
(C) 1998 Jan Rychter

Niniejszy artykuł można kopiować i rozprowadzać wyłącznie w całości na
zasadach licencji GNU w wersji 2 lub dowolnej późniejszej wersji.

Dla "Magazynu Linux/UNIX", wrzesień/98
$Id$

 [ ZMailer jest szybkim i bezpiecznym MTA (Mail Transfer Agent) dla
   systemów UNIX. Zajmuje się rozsyłaniem i przekazywaniem poczty
   elektronicznej, otrzymanej od programów MUA (Mail User Agent) takich jak
   mutt, pine, elm, od procesorów list dyskusyjnych (majordomo, petidomo,
   listserv) lub od innych maszyn w sieci. Odgrywa w systemie rolę podobną
   do powszechnie znanego i stosowanego programu sendmail, różni się jednak
   od niego znacznie na korzyść jeżeli chodzi o bezpieczeństwo i
   wydajność. W poprzedniej części opisana została jego architektura i
   sposób kompilacji, w tej zajmę się instalacją i konfiguracją. ]


Instalacja, uruchamianie


Sama instalacja poprawnie skompilowanego ZMailera sprowadza się w
zasadzie do wydania komendy "make install". Reszta powinna przebiegać
automatycznie. Warto jednak zwrócić uwagę na zainstalowanie poprawnego
skryptu startującego ZMailer przy starcie systemu i zatrzymującego go
przy wyłączaniu systemu. Nie będzie on skomplikowany, gdyż poprawnym
uruchomieniem (i zatrzymaniem) wszystkich procesów ZMailera zajmuje się
jego własny skrypt "zmailer". Dla ścieżek podanych w poprzedniej części
artykułu znajdzie się on w katalogu /local/lib/mail/bin.

Uruchomienie ZMailera odbywa się więc poprzez:

/local/lib/mail/bin/zmailer

zaś zatrzymanie poprzez:

/local/lib/mail/bin/zmailer kill

Warto zwrócić uwagę, że wieloprocesowa architektura ZMailera umożliwia
zatrzymywanie i uruchamianie poszczególnych jego części, bez wpływu na
działanie pozostałych. Przydatne warianty to na przykład:

 -- zmailer kill router -- zatrzymanie procesu router. System będzie
    nadal przyjmował pocztę (zajmuje się tym smtpserver) i wysyłał już
    przetworzoną pocztę (co z kolei nadzoruje scheduler).
 -- zmailer kill scheduler -- system będzie przyjmował pocztę i
    przetwarzał ją, ale nie będzie rozsyłał ani dostarczał
    lokalnie. Szczególnie przydatne dla systemów które tylko czasowo są
    podłączane do Internetu, ZMailer z wyłączonym schedulerem zachowuje się
    podobnie jak sendmail z opcją "queueonly".
 -- zmailer kill smtpserver -- system będzie przetwarzał pocztę
    znajdującą się już w kolejkach, a także ją rozsyłał, nie przyjmie za to
    nic nowego poprzez SMTP. Przydatne w (rzadkich) przypadkach
    przeciążenia.

Każdy z procesów można oczywiście uruchomić, komendami:
    zmailer router
    zmailer scheduler
    zmailer smtpserver

Rzecz jasna określenie "proces" jest w tym kontekście umowne, gdyż
np. procesów typu "router" może w systemie być wiele.


Routing poczty


Pierwszym krokiem przy konfiguracji ZMailera jest zapewnienie mu
odpowiedniego pliku konfiguracyjnego dla procesu "router". Standardowa
konfiguracja "SMTP+UUCP.cf" z pewnością wystarczy dla większości
przypadków. Należy ten plik skopiować (lub podlinkować) do katalogu
/local/lib/mail (lub innego w którym zainstalowany został ZMailer) pod
nazwą "router.cf". Przy pierwszym uruchomieniu ZMailer "skompiluje"
sobie ten plik do zoptymalizowanej postaci, której nada nazwę
"router.fc".

Następnie należy zajrzeć do katalogu /local/lib/mail/db. Znajduje się
tam plik "routes", początkowo zawierający tylko komentarze. Służy on do
konfiguracji "routingu" poczty elektronicznej. Pojęcie to jest nieco
nietypowe dla innych MTA niż ZMailer, stanowi jednak bardzo wygodny
mechanizm do konfigurowania niestandardowego rozprowadzania poczty.

Poszczególne linie w pliku "routes" są w postaci:

nazwa    kanał!komu_przekazać

"nazwa" dopasowywana jest do części adresu po znaku "@", przy czym można
używać nazw .domena dla oznaczenia wszystkiego co ta domena zawiera.

"kanał" odpowiada odpowiedniemu kanałowi skonfigurowanemu w pliku
"scheduler.conf".

Znaczenie parametru "komu_przekazać" zależy od rodzaju kanału. Dla
"smtp" jest to po prostu adres następnej maszyny której należy przekazać
pocztę.

Przykład:

.pl             smtp!smtp-gw.rgstudio.com.pl
.rgstudio       smtps!intranet.rgstudio.com.pl

Powyższe linie oznaczają, że poczta z adresami kończącymi się na .pl
przekazana zostanie maszynie "smtp-gw.rgstudio.com.pl", zaś poczta z
adresami .rgstudio (wewnętrzna domena, nie istniejąca w Internecie)
komputerowi "intranet", ale przez specjalny kanał "smtps"
(skonfigurowany w "scheduler.conf" i zapewniający szyfrowanie). Każdy
inny list będzie traktowany indywidualnie, komputer który konfigurujemy
będzie go sam próbował wysłać w świat.

Należy pamiętać, że cały plik "routes" musi być zawsze posortowany,
włącznie z komentarzami.


Nazwy kanoniczne


Plik /local/lib/mail/db/localnames jest odpowiednikiem pliku
"sendmail.cw" w konfiguracji sendmaila. Daje jednak nieco więcej
możliwości, gdyż specyfikuje się w nim rozwinięcia lokalnych nazw
komputera, używane później przy przepisywaniu nagłówków i dostarczaniu
poczty.

Przykładowo:

intranet                 intranet.rgstudio.com.pl
intranet-gw              intranet.rgstudio.com.pl
intranet.rgstudio.com.pl intranet.rgstudio.com.pl
localhost                intranet.rgstudio.com.pl
localhost.localdomain    intranet.rgstudio.com.pl

W tym przykładzie maszyna o nazwie kanonicznej
"intranet.rgstudio.com.pl" odbierać będzie jako przeznaczoną dla siebie
pocztę adresowaną na wszystkie nazwy występujące po lewej stronie. Nawet
w przypadku gdy otrzyma pocztę adresowaną dla "intranet-gw", całe dalsze
przetwarzanie będzie się odbywać tak samo, jakby była adresowana dla
"intranet".

Należy pamiętać, że podobnie jak plik "routes", cały plik "localnames"
musi być zawsze posortowany, włącznie z komentarzami.


Aliasy, aliasy FQDN


Plik definiujący aliasy w ZMailerze znajduje się (w naszej instalacji) w
katalogu /local/lib/mail/db. Odświeżenie bazy aliasów odbywa się po
wykonaniu komendy "newaliases". Warto zwrócić uwagę na to, by została
wykonana właściwa komenda "newaliases", ta z katalogu z binariami
ZMailera. Często przez przeoczenie pozostaje w systemie "newaliases" z
programu sendmail.

Warto też przyjrzeć się sposobowi definiowania aliasów w ZMailerze. Nie
jest on identyczny do tego z sendmaila. W szczególności, ZMailer wymaga
by prawe strony bardziej skomplikowanych aliasów występowały w
cudzysłowach. Dla przykładu:

autoanswer: "|/local/lib/mail/bin/autoanswer.pl"
lista-outgoing: ":include:/local/majordomo/lists/lista"
staff: "jwr,mk"

Lewa strona wszystkich aliasów powinna być złożona wyłącznie z małych
liter, nie można też definiować aliasów zawierających znak
kropki. Jedynym sposobem na dostarczanie poczty na adresy rodzaju
"Imię.Nazwisko@domena" w ZMailerze jest baza "fullnames".

Bazę "fullnames" tworzy się w prosty sposób. Jest to plik (w naszej
instalacji w katalogu "/local/lib/mail/db") "fullnames", zawierający
pary "Imię.Nazwisko: login". Do odświeżania służy komenda "newaliases
fullnames". Tak utworzona baza jest automatycznie wykorzystywana przy
następnym uruchomieniu procesu "router".

Ciekawym mechanizmem jest baza "fqdnaliases". Do tych aliasów
przychodząca poczta dopasowywana jest przed jakimkolwiek innym
przetwarzaniem. Pozwalają one między innymi na obsługę "domen
wirtualnych" w dość prosty sposób:

uzytkownik@inna-domena.com.pl: lokalny-uzytkownik@rgstudio.com.pl

Oczywiście jedynie "lokalny-uzytkownik" musi istnieć lokalnie, zaś
"uzytkownik" będzie istnieć tylko z adresem
"uzytkownik@inna-domena.com.pl. Wysłanie poczty na adres
"uzytkownik@rgstudio.com.pl" zakończy się błędem. Do odświeżania tej
bazy służy komenda "newfqdnaliases".

W ZMailerze istnieje też rozbudowany mechanizm definiowania bardzo
szybko przetwarzanych list dyskusyjnych (z automatycznie definiowanymi i
rozpoznawanymi aliasami lista-owner, lista-request itp), o którym być
może napiszę w jednym z kolejnych artykułów. Jest on znacznie
optymalniejszy i łatwiejszy w użyciu niż definiowanie list na wzór
programu "sendmail" (dyrektywa ":include:").


Konfiguracja dostarczania poczty


ZMailer pozwala na daleko idące konfigurowanie sposobu dostarczania
poczty. Poczta w systemie dzielona jest na tzw. kanały, których
przetwarzaniem zajmuje się proces "scheduler". Uruchamia on odpowiednie
programy dostarczające pocztę ("transfer agents").

Dokładny opis pliku konfiguracyjnego "scheduler.conf" wykracza niestety
poza ramy tego artykułu, przytoczę więc jedynie dwa dość przydatne
przykłady:

smtp/*.pl
        expiry=7d
        maxta=60
        command="smtp -s"

Ten przykład przedłuża czas przez jaki próbujemy dostarczyć pocztę do
siedmiu dni, pozwala też na uruchomienie aż do 60 (!) równolegle
pracujących procesów dostarczających pocztę. Wszystko to tylko dla
adresów w domenie .pl, pozostałe adresy przetwarzane są zgodnie ze
standardowymi parametrami.

local/*
        expiry=3d
        command="sm -8c $channel cyrus"

W tym przypadku wymieniamy lokalny program dostarczający pocztę na "sm"
(o którym dalej) z parametrem "cyrus". Cyrus-IMAP jest to system
przeznaczony dla większych providerów internetowych, pozwala na łatwą i
wydajną obsługę dużych ilości kont E-pocztowych z dostępem poprzez
protokół IMAP.


Kompatybilność z programem "sendmail"


ZMailer zawiera dwa istotne elementy służące do zapewnienia zgodności z
programem "sendmail". Jeden, to sam program o nazwie "sendmail",
zapewniający większość opcji z linii komend prawdziwego sendmaila i
pozwalający na bezbolesne wpięcie ZMailera w istniejące systemy. Służy
on do wysyłania poczty lokalnie.

Drugim takim elementem jest program ("transfer agent") o nazwie
"sm". Pozwala on na definiowanie lokalnych sposobów dostarczania poczty
w sposób podobny do sendmaila. Jego plikiem konfiguracyjnym jest
"sm.conf", w którym definiować można przykładowo:

# wyżej wspomniane połączenie z systemem Cyrus-IMAP
cyrus   Pn      /usr/cyrus/bin/deliver          deliver -e -m $h -- $u
# procmail jako program dostarczający pocztę lokalnie
procm   sSPfn   /usr/local/bin/procmail         procmail -a $h -d $u

Pierwszy parametr to nazwa kanału, odpowiada ona wpisowi w polu
"command" odpowiedniej sekcji "scheduler.conf". Pozostałe parametry
wzorowane są na konfiguracji programu sendmail.


Kontrola przekazywania poczty ("relaying")


Aby zabezpieczyć się przed nieoczekiwanym wykorzystaniem naszego systemu
jako otwartego przekaźnika pocztowego ("open mail relay") przez firmy
rozsyłające masowo niechcianą reklamę (spam), warto poprawnie
skonfigurować zasady na jakich nasz system pocztę będzie
przekazywał. Służy do tego zestaw plików "smtp-policy.*" (w naszej
instalacji w katalogu /local/lib/mail/db). Podstawowym plikiem jest
"smtp-policy.src", z którego generowana jest baza regułek antyspamowych.
Dokładny opis wszystkich możliwości filtrowania poczty oraz stosowanego
algorytmu nie zmieściłby się w ramach tego artykułu, poprzestanę więc na
opisaniu pokrótce kilku przykładów. Pełen algorytm i sporo przykładów
podanych jest w pliku "smtp-policy.src".

Najistotniejszą rzeczą jest zdefiniowanie standardowej polityki naszego
systemu odnośnie przekazywania poczty. Zaleca się dwie następujące
linijki:

.                     relaycustomer - relaytarget - senderokwithdns +
[0.0.0.0]/0           relaycustomer - relaytarget - senderokwithdns +

Oznaczają one, że o ile dalej nie wyspecyfikujemy inaczej, nie pozwalamy
na żadne przekazywanie poczty przez nasz system oraz wymuszamy
sprawdzanie istnienia domeny wysyłającego w DNS. Rzecz jasna system
nadal będzie przyjmować pocztę zaadresowaną do siebie (czyli do maszyn i
domen zapisanych w pliku localnames) oraz pozwalał na wysyłanie poczty
od siebie do całego świata.

Do odświeżania bazy reguł anti-relay służy skrypt
"policy-builder.sh". Warto zmodyfikować go nieco do własnych
potrzeb. Oryginalny (w źródłach ZMailera) używa programu "lynx" by
ściągnąć z sieci listę adresów i domen znanych z rozsyłania reklam do
pliku "smtp-policy.spam". Używa też plików "localnames",
"smtp-policy.relay" i "smtp-policy.mx" do wygenerowania uproszczonej
konfiguracji. Polityka przyjmowania i przekazywania poczty na każdym
systemie jest inna, warto więc spędzić trochę czasu nad poprawnym i
starannym skonfigurowaniem tego.

Wszelkie decyzje podjęte na temat przyjmowanej poczty będą zapisane
przez proces "smtpserver" w jego logach (w naszej instalacji:
"/var/log/mail/smtpserver"), wraz z komunikatami jakie zostały odesłane
łączącym się klientom w przypadku odrzucenia.


Podsumowanie


Szczegółowe opisanie możliwości konfiguracji ZMailera wymagałoby całej
serii artykułów, z konieczności więc ograniczyłem się do opisania tylko
podstawowych opcji. Jest to program który pozwala na bardzo dużo, jest
też o wiele logiczniejszy w konfiguracji niż sendmail (szczególnie język
skryptów routera poczty).

Istnieje możliwość (jeśli będzie zainteresowanie) przedłużenia cyklu
artykułów o ZMailerze i szerszego opisania (wraz z przykładami)
konkretnych aspektów jego konfiguracji, lub konkretnych rozwiązań
(przykładowo: ZMailer+Cyrus, ZMailer+listy dyskusyjne na dużą skalę,
ZMailer+filtrowanie poczty przez RBL -- Realtime Black Hole). Piszcie do
redakcji na adres <redakcja@tao.com.pl> -- dajcie znać co sądzicie o
artykułach które już się pojawiły i o czym chcielibyście przeczytać.


[ stopka:

RG Studio zajmuje się doradztwem Linux/UNIX, instalacjami systemów,
utrzymaniem i zabezpieczaniem istniejących instalacji, oraz sprzedażą
specjalizowanego sprzętu związanego z Linuxem: kart frame-relay Sangoma
Technologies i Emerging Technologies, mikroserwerów Cobalt Qube firmy
Cobalt Networks, płyt głównych i procesorów Samsung Alpha, a także kart
wieloportowych Cyclades i sprzętu Gigabit Ethernet firmy Packet
Engines. Kontakt: E-poczta: info@rgstudio.com.pl, WWW:
http://www.rgstudio.com.pl/, Adres: RG Studio, Limanowskiego 23, 02-934
Warszawa, Tel./Fax.: (22) 6516638.

Z autorem można skontaktować się pod adresem: Jan Rychter
<jwr@rgstudio.com.pl>

]