|
wersja 2.60 |
|
Spis treści |
ChangeLog 1. Czym jest Postfix ? 2. O instalacji 3. Rzut oka na pliki konfiguracyjne. 4. Podstawowe polecenia. 5. Mój pierwszy raz. 6. A co gdy mam modem ? 7. Zmiana adresu nadawcy przy wysyłaniu poczty. 8. Adresy poczty przychodzącej. 9. Gdy kogoś zabraknie. 10. Usuwanie listu z kolejki. 11. Restrykcje (na podstawie:) a. Adresu IP komputera wysyłającego b. Adresu e-mailowego nadwacy c. Adresu e-mailowego odbiorcy 12. Wirtualne domeny a. w stylu postfixa b. w stylu sendmaila 13. Powiadamianie na komórkę (Plus GSM) 14. Powiadamianie na GaduGadu 15. Postfix + MKS vir 16. Statystyki 4 Postfix. 17. Oczekując na błąd 18. Jaki serwer ? 19. Inne. 20. Postfix + TLS. Posłowie |
| ChangeLog |
Zmiany od wersji 1.1 tego dokumentu: - poprawiono kilka błędów rzeczowych, dopisano kilka ciekawych spraw, całkowicie zmieniono (i rozbudowano) restrykcje. Zmiany od wersji 1.9a: - dodano statystyki. Zmiany od wersji 2.0: - dodano opis obsługi virtualnych domen. Zmiany od wersji 2.1: - powiadamianie na komórę o poczcie (SMS na Plus GSM) Zmiany od wersji 2.2: - program antywirusowy Zmiany od wersji 2.3: - dopisano kilka ciekawych rzeczy do "innych", dodano "oczkując na błąd" oraz "jaki serwer ?" Zmiany od wersji 2.4: - nie było takiej wersji :) Zmiany od wersji 2.5: - powiadamianie na GG o nowej poczcie, drobiazgi w ostatnim punkcie Zmiany od wersji 2.6: - postfix + TLS |
| 1. Czym jest Postfix ? |
Jeśli używasz Linuxa, prawdopodobnie serwerem poczty na twoim komputerze jest program Sendmail. Co o nim wiemy ? * zyskał sobie sławę jako najbardziej dziurawy program unixowy. Istnieją dziesiątki sposobów, przez które można (było) "namieszać" w systemie dzięki temu progsowi. * jest trudny w konfiguracji. Jeśli kiedykolwiek próbowałeś to robić, wiesz o co chodzi. Jeśli nie, nie będziesz miał okazji - po przesiadce na Postfixa :) To było przypomnienie, powróćmy do Postfixa. Jest to serwer poczty, pozbawiony wad Sendmaila. Został od początku pisany jako progam mający być szybki, bezpieczny i łatwy w administracji. Jakby nie patrzeć, Postfix bardzo szybko zdobywa popularność i nic nie wskazuje na to, że to się zmieni. Chyba już czas przesiąść się na Postfixa. Jedziemy! |
| 2. O instalacji |
Program można pobrać spod adresu www.postfix.org. Znajduje się tam także dokumentacja, FAQ itp. Instalacja nie powinna stwarzać żadnych problemów. Jeśli coś pójdzie nie tak, szukamy pomocy w dokumentacji. Ja zakładam, że wszystko zostało pomyślnie zainstalowane. Wspomnę tylko o tym, że będziemy musieli dodać do naszego systemu nowego użytkownika "postfix" i grupę "postdrop". Tak jest przynajmniej w Slacku, nie wiem, czy w RedHacie automatycznie go doda. Tak czy inaczej należy czytać dokumentację. Następnie pozbywamy się Sendmaila. Proponuję się nie wahać i zrobić to tak, jak sugeruje dokumentacja Postfixa: - jeśli łączymy się z Inetem przez modem, i mamy skolejkowaną, jeszcze nie wysłaną pocztę (mailq), łączymy się z Siecią i wysyłamy zaległą pocztę (sendmail -q). - jeśli sendmail jest uruchomiony (ps x) musimy go zamknąć. Raz na zawsze :) Ja go po prostu kill'nąłem, choć prawdopodobnie istnieje na to jakiś bardziej cywilizowany sposób. - teraz szukamy pliki sendmaila (`which sendmail`), zmieniamy ich nazwę poprzez polecenie `mv sendmail sendmail.OFF` a następnie zabieramy prawa (m.in. suida) temu plikowi: `chmod 700 sendmail.OFF`. - usuwamy wywołanie Sendmaila ze skryptów startowych. Chodzi o katalog /etc/rc.d/ w przypadku Slacka, jeśli RedHat, to chyba gdzieś w /etc/rc.d/init.d. W którymś z plików rc.X znajdujemy wywołanie sendmaila, usuwamy je, lub wstawiamy # (hash) przed linijkę z wywołaniem. W to miejsce możemy od razu wpisać `postfix start`. - jeśli nasz klient poczty tego wymaga, odpowiednio go ustawiamy. W przypadku Pine, który domyślnie sam wywołuje sendmaila, wchodzimy do: Setup-->Config a następnie w pole "smtp-server"wpisujemy localhost. Oczywiście jeśli to nasz komp ma być serwkiem poczty. Nie wiem, jak jest w przypadku innych klientów poczty, ale pewnie podobnie. Dobra, to chyba tyle. Od tego miejsca zakładam, że sendmail nie jest uruchomiony, oraz że postfix został poprawnie zainstalowany. |
| 3. Rzut oka na pliki konfiguracyjne |
Pliki konfiguracyjne programu Postfix umieszczone są w katalogu /etc/postfix. Rzuć tam okiem. Najważniejszym plikiem jest main.cf. Znajdują się w nim wszystkie najważniejsze opcje działania programu postfix. Jeśli się mu przyjrzysz, stwierdzisz, że są one dobrze opisane, co ułatwi Tobie już niedługo zmianę jego parametrów. Kolejnymi plikami, o których warto wspomnieć, są pliki sample-...... Zawierają one wskazówki o tym, jak zmieniać poszczególne opcje działania postfixa. Pliki te okażą się bardzo przydatnymi, jeśli będziesz wprowadzał jakiekolwiek zmiany. Innymi ważnymi plikami są pliki o pewnej nazwie, bez rozszerzenia, oraz odpowiadające im pliki o tej samej nazwie z rozszerzeniem .db. Przykład: aliases oraz aliases.db. To m.in. dzięki nim konfiguracja naszego serwera poczty jest taka prosta. |
| 4. Podstawowe polecenia |
Do wywoływania poniższych poleceń potrzebne są, o ile się nie mylę, uprawnienia root'a. Co możemy zrobić z serwerem poczty ? * możemy go uruchomić: postfix start * możemy go także zatrzymać: postfix stop * możemy go "zrestartować": postfix reload Nie wiem dlaczego, to ostatnie kojarzy mi się z M$ Windows... Jeszcze nic nie uruchamiaj, poczekaj do następnego punktu. Ta trzecia możliwość jest przydatna, gdy zmienimy pliki konfiguracyjne programu. Nie musimy wtedy postfixa zatrzymywać i uruchamiać od nowa, co daje w sumie 2 komendy :) Wystarczy wywołać "reload", aby program zrestartował się, wczytując nowe ustawienia. Pamiętajmy, że po każdej zmianie w plikach konfiguracyjnych, należy program przeładować (to jeszcze jedna nazwa na restart). Teraz o przydatnym poleceniu postconf. Pozwala ono zobaczyć wartości poszczególnych parametrów, zmiennych, zmiennych konfiguracyjnych, jak zwał, tak zwał. Dla przykładu wywołaj np. `postconf myhostname`. Narzędzie to przydaje się, gdy szukamy dziury w całym - nie bardzo wiemy dlaczego coś nie działa i szukamy jakiegoś punktu zaczepienia, jakiejś wskazówki lub gdy sprawdzamy jakie wartości mają poszczególne zmienne programu. |
| 5. Mój pierwszy raz |
Jeśli postępowałeś zgodnie z punktem 2, nic nie stoi na przeszkodzie aby sprawdzić nowy serwer poczty. Jako root musimy najpierw zmodyfikować trochę plik /etc/postfix/main.cf. Otwieramy go w ulubionym edytorze, np. vi, pico, co kto lubi. Musimy teraz poinformować program: * jak nazywa się nasz komputer: szukamy linijki o tereści: myhostname = host.domain.name i zmieniamy 'host.domain.name' na nazwę naszego komputera. Gdy nasz komp nazywa się np. polska.pl pozostawiamy wpis:myhostname = polska.pl. * zmienna mydestination = . Prawdopodobnie najlepszą wartością będzie tu mydestination = $myhostname dlatego jeśli jest inaczej, zmieniamy ją. * jeśli chcemy logować adresy IP komputerów wysyłających pocztę, a nie ich nazwy: disable_dns_lookups = na disable_dns_lookups = yes . Jeśli dana zmienna nie istnieje, stwórzmy ją i nadajmy powyższą wartość. Plik ten jest dobrze opisany, więc czytajmy przy okazji komentarze. Uważajmy, zby nie zrobić "literówki", wpisujmy dokładnie warości. Jeśli nie jesteśmy pewni, co do nazwy jakiejś zmiennej, użyjmy polecenia 'postconf |more' aby zobaczyć możliwe nazwy zmiennych. Dobra, zapisujemy zmiany. Możemy teraz odpalić postfixa. Jako root (superużytkownik) wpisujemy polecenie 'postfix start'. Powinno to wyglądać tak: # postfix start postfix-script: starting the Postfix mail system Dobra, wszystko jest ok. Możemy teraz spróbować wysłać pocztę do jednego z naszych lokalnych użytkowników. Jeśli coś pójdzie nie tak upewnij się, że Twój klient poczty nie potrzebuje zmiany konfiguracji. Jeśli ciągle coś nie działa, przeczytaj jeszcze raz punkt 2, tym razem dokładnie ;). Jeśli list dotarł do (przypominam, ważne: lokalnego) odbiorcy, gratuluję, teraz będzie już z górki. |
| 6. A co gdy mam modem ? |
Jeśli korzystasz z usług naszego monopolisty, TP s.a. to masz pecha. Tak zresztą, jak ja. Na początek wyrazy współczucia. Dobra, bierzemy w obroty /etc/postfix/main.cf. * potrzebujemy zmiennej relayhost = . Jeśli takiej nie ma, tworzymy ją. Jej wartość wskazuje na komputer, przez który poczta będzie wysłana. Wpisujemy warto ść jakiegoś serwera poczty, np. poczta.onet.pl. Uwaga: nie wszystkie "zewnętrzne" serwery poczty akceptują wysyłanie poczty przez siebie, dlatego najpierw upewnij się, że listy wysłane przez niego trafiają do celu. Ja używam do tego celu komputera poczta.interia.pl i nie narzekam - jak na razie działa bezbłędnie. W każdym razie: relayhost = poczta.interia.pl * druga rzecz, którą musimy zrobić to wprowadzić do zmiennej defer_transports wartość "smtp". Ostatecznie mamy: defer_transports = smtp I to wszystko, fajne, co ? Dobra. Pewnie chciałbyś, aby po wejściu do Inetu, skolejkowana poczta była automatycznie wysyłana. W tym celu do pliku /etc/ppp/ip-up (tu on jest w Slacku) wpisujemy postfix flush. Teraz po każdym połączeniu, skolejkowana poczta będzie wysłana poprzez komputer ze zmiennej "relayhost". Nie zapomnij przeładować postfixa (postfix reload). A teraz połącz się z Inetem i zobacz, czy toto działa. Pozostaje jeszcze jedna sprawa: jeśli wyślesz list do kogoś, w jego polu Od: (From:) będzie twój tutejszy adres nadawcy, np. root@localhost. Jak to zmienić ? Odpowiedź poniżej. |
| 7. Zmiana adresu nadawcy przy wysyłaniu poczty |
Jeśli bawimy się w listy na lokalnym komputerze, nie ma problemu. Gdy komputer nazywa się np. polska.pl to mamy adresy np. linio@polska.pl, root@polska.pl. W sieci lokalnej szafa gra. Gorzej, gdy chcemy wysłać wiadomość w świat. Wówczas w polu From: będzie np. linio@poczta.pl. Jako, że nie mam takiego konta wypadałoby, żeby przy wysyłaniu poczty, postfix automatycznie zmieniał mój adres nadawcy na inny, taki, jaki posiadam na serwerze terramail.pl Innym zastosowaniem tego, jest możliwość zmiany loginów lokalnych użytkowników na ich imiona i nazwiska. Ostatnio stało to się bardzo popularne. Na przykład hnk@polska.pl wysyła list, i odbiorca dostaje go od Henryk.Aktinowski@polska.pl. Dobra, jak to zrobić: ==> Na początek bierzemy w obroty /etc/postifx/main.cf. Szukamy zmiennej sender_canonical_maps = . Jeśli nie ma ona wartości, jest ignorowana przez hash (#) lub ma inną wartość niż hash:/etc/postfix/sender_canonical , nadajemy jej taką wartość i odhash'owujemy ją. Ostatecznie: sender_canonical_maps = hash:/etc/postfix/sender_canonical . Jak możesz się domyślać, w pliku tym będą znajdować się nasze mapowania jednych użytkowników w innych (dokładnie: adresów). Zapisujemy zmianę. ==> Jeśli nie istnieje plik /etc/postfix/sender_canonical, tworzymy go. Jeśli istnieje, na jego końcu dopisujemy odwzorowywania adresów na inne: a) w przypadku łączenia się przez modem: linio [tutaj spacja lub tabulator] linio@terramail.pl czesiek czs@interia.pl jaca yaca@poczta.onet.pl Co to znaczy ? Adresy e-mail lokalnych użytkowników o loginach linio, czesiek, jaca będą zmienione odpowiednio na linio@terramail.pl, czs@interia.pl i yaca@poczta.onet.pl. Tak więc spokojnie można wysyłać pocztę przez nasz komputer, bo nadawca w polu From: listu wychodzącego będzie odpowiednio zmieniona. b) w przypadku stałego połączenia z Inetem, gdy nazwa naszego komputera jest nazwą naszego komputera w Internecie, możemy wykorzystać ten fakt do zamiany adresów e-maili z loginów na np. imiona i nazwiska. Wówczas w tym pliku wpisujemy np. linio [tu spacje lub tabulatory] Heniek.Liniowski czesiek Czeslaw.Penerski hnk Henryk.Aktinowski itd. Wówczas w polu From: widoczne będzie imię i nazwisko osoby wysyłającej list. Dobra. c) Pozostało zakutalizować naszą bazę danych w pliku 'sender_canonical' i przeładowanie postfixa. A robi to się tak: postmap /etc/postfix/sender_canonical postfix reload Pamiętajmy, że po każdej zmianie bazy danych, odwzorowań w pliku 'sender_canonical' należy ją uaktualnić poleceniem 'postmap'. Dobra, to wszystko na ten temat. Pozostaje jeszcze jedna sprawa: jeśli nasz komputer (teraz zakładam stałe połączenie z Netem), wysyła list i zamienia hnk na Heniek.Aktinowski jest fajnie. Ale nie ma on pojęcia, co zrobić z listem przychodzącym do Heniek.Aktinowski@..... Jak temu zaradzić ? Patrz: następny punkt. |
| 8. Adresy poczty przychodzącej |
Aliasy znajdują zastosowanie m.in. wtedy, gdy stosujemy zmianę adresów poczty wychodzącej. Weźmy dla przykładu Henryka. Jego login hnk jest przy wysyłaniu zamieniony na Henryk.Atkinowski. Jeśli ktoś odpisze na jego list, trafi on do naszego komputera. Nie mamy jednak użytkownika o takim loginie. Tu właśnie wkraczają aliasy. Ich kolejnym zastosowaniem może być możliwość tego, że jedna osoba posiada kilka aliasów i np. poczta do Heniek.Atkinowski@...., Henryczek@..... itd. trafiać będzie do jednej osoby. Jeszcze innym zastosowaniem jest możliwość taka, że tworzymy zbiorowy alias dla kilku użytkowników. Przykładowo list adresowany do admini@..... trafi do skrzyniki użytkowników root, linio, czesiek. Dobra, wystarczy tej teorii. Jak to zrobić ? --> domyślnym plikiem będącym bazą odwzorowań aliasów jest plik /etc/aliases. Wrzućmy go do naszego edytora i dopiszmy na końcu: Henryk.Atkinowski: hnk Henryczek: hnk Czesik.Penerski: czesiek admini: root, linio, czesiek Chyba łapiesz, o co chodzi. Oczywiście wpisuj takie aliasy, jakie Ci pasują a nie powyższe. Zwrócę jescze tylko uwagę na dwukropek, który występuje po każdym aliasie. Dobra, zapisujemy zmiany. --> pozostało jeszcze uaktualnić bazę danych aliasów. Używamy do tego linuxowego polecenia newaliases. Nie pomylcie go z innym poleceniem, newalias. Dobra. Pozostało tylko przeładować postfixa (postfix reload). Gdybyście chcieli zmienić plik z bazą danych aliasów na inny, należy zmienić w /etc/postfix/main.cf wpis dla zmiennej alias_maps = na inny, oraz alias_database = ale sami się w to bawcie jeśli domyślne Wam nie odpowiadają. |
| 9. Gdy kogoś zabraknie |
O co chodzi ? Załóżmy, że na naszym kompie, przez dłuższy czas miał konto jacek. Jego adresem był jacek@polska.pl. Nasz komputer (polska.pl) odbierał i wysyłał dla niego pocztę. Ale Jacek się wyprowadził lub został wyrzucony. W każdym razie już go nie ma, ale ludzie ciągle piszą listy do niego na ten adres. Co możemy zrobić ? Możemy tak skonfigurować postfixa, żeby automatycznie, bo odebraniu poczty dla jacka, wysyłał automatycznie odpowiedź, do nadawcy listu, że jacek juz tu nie ma konta, możemy podać także nowy adres lub inny kontakt z jackiem, np. jego nr telefonu. W każdym razie czaisz o co chodzi. A robi się to tak: --> Wrzucamy do edytora plik /etc/postfix/main.cf (znowu on). Szukamy zmiennej relocated_maps. Jeśli jej nie ma, jest ignorowana poprzez hash (#) lub nie ma nadanej wartosći, wówczas tworzymy ją i nadajemy wartość hash:/etc/postfix/relocated W sumie wygląda to tak: relocated_maps = hash:/etc/postfix/relocated Dobra, chyba już wiesz, że trzeba zapisać zmiany i wyjść z edytora. --> Jeśli nie istnieje plik /etc/postfix/relocated, to go tworzymy. Jeśli istnieje, wrzucamy go do edytora. Składnia jest taka: login "ewentualny komentarz w cudzysłowiu". Załóżmy, że już nie ma nieszczęsnego jacka, wówczas wpisujemy tam: jacek "Jacek zmienił swój adres na jacek@pcim.pl" Jeśli teraz ktoś wyśle e-mail do jacka dostanie on od razu list zwrotny, że tego usera już tu nie ma i że "Jacek zmienił swój adres na jacek@pcim.pl" Wprowadzamy tyle osób, ile tylko chcemy, ale każda z nich, a dokładnie komentarz, powienien się zmieścić w jednej linijce. Gdy komentarz składa się z więcej niż jednego wyrazu, piszemy go w cudzysłowiu. Dobra,zapisujemy zmiany. --> Dalej już chyba wiesz. Wywołujemy postmap /etc/postfix/relocated, a następnie przeładowujemy postfixa: postfix reload. Pobawcie się w to sami, spróbujcie wysłać coś do takiej osoby. |
| 10. Usuwanie listu z kolejki |
Oki. Załóżmy, że mamy sobie modem (i płacimy złodziejskie opłaty dla monopolisty). Załóżmy, że postfix przyjął list do kogos@gdzies.pl oraz go skolejkował. List czeka na wysłanie a to odbędzie się przy najbliższym połączeniu z Inetem. Jednak nadawca tego listu się rozmyślił/zmienił zdanie/wytrzeźwiał i już nie chce żeby list został wysłany. Co możemy zrobić ? --> Musimy dowiedzieć się numer identyfikacyjny (ID) skolejkowanego listu. Robimy to wydając polecenie mailq. Po adresie nadawcy i odbiorcy poznajemy, który list należy cofnąć. Do usunięcia listu z kolejki, wykorzystujemy ID listu. Wygląda on mniej - więcej tak: 90E8A5647C. Ale tajemnicza nazwa ! --> Gdy znamy ID listu, jedyne co musimy zrobić to usunąć pliki o takiej nazwie z katalogu /var/spool/postfix. W tym celu wchodzimy do katalogu /var/spool/postfix i wydajemy polecenie: find incoming active deferred -name 90E8A5647C -print |sed 1q|xargs rm Wygląda to na trochę skomplikowane. Jak się gubisz, znajdź ten plik ręcznie i go usuń. Tak po prostu. Nie muszę chyba pisać, że w miejscu 90E8A.... wpisujesz ID listu, który chcesz usunąć. Gdy go usuniesz i chcesz się upewnić, że jest usunięty z kolejki, jeszcze raz wydaj polecenie `mailq`. Powinno go już tam nie być. |
| 11. Restrykcje |
Teraz przydałoby się napisać parę rzeczy o restrykcjach. Czego mają one dotyczyć ? Na pewno zdajesz sobie sprawę, że możliwe jest "anonimowe" wysyłanie e-maili przez serwer pocztowy. Polega to z grubsza na telnetowniu się na 25 port serwera i wpisywaniu odpowiednich poleceń. W rezultacie możliwe jest wysyłanie listów z dowolnym adresem nadawcy. Możliwe jest też wysłanie przez nasz komputer np. listu z pogróżkami przez dowolny komputer z sieci. "Bad boys" nigdy nie śpią. Dobra, wystarczy tego czarnego scenariusza. Opisałem tutaj możliwe restrykcje do nałożenia oraz ich najczęściej używane wartości, opcje. Opiszę tutaj trzy rodzaje możliwych restrykcji: - na podstawie adresu IP/nazwy kompa łączącego się z naszym serwerem - na podstawie adresu nadawcy listu - na podstawie adresu odbiorcy listu |
| 11a. na podstawie adresu IP/nazwy kompa łączącego się z naszym serwerem |
Operujemy oczywiście na pliku main.cf. Do tego typu ograniczenia służy zmienna smtpd_client_restrictions. Domyślna konfiguracja pozwala na połączenia każdemu komputerowi klienckiemu. Możemy wprowadzić następujące ograniczenia: * permit_mynetworks - pozwala na połączenie się z naszym serwerem komputerom, z naszej sieci lokalnej (dokładnie: komputerom, które pasują do zmiennej $mynetworks) * reject_unknown_client - odrzuca komputer, którego adres IP nie ma wpisu w DNS * check_client_access maptype:mapname - sprawdza IP/nazwę komputera w pliku wpisanym jako parametr. Zawiera on dane co zrobić z danym komputerem. Opisane na końcu rozdziału. * permit - pozwól na połączenie. Przydatne na końcu listy ograniczeń, jako zachowanie domyślne, gdy poprzednie reguły nie pasują. * reject - odrzuć połączenie. Przydatne na końcu listy ograniczeń, jako zachowanie domyślne, gdy poprzednie reguły nie pasują. Przykłady: smtpd_client_restrictions = permit_mynetworks, reject pozwala na wysyłanie listów tylko komputerom z naszej sieci lokalnej (o ile dobrze zdefiniowana jest zmienna $mynetworks). Jest to dobre rozwiązanie dla sieci lokalnej, jeśli wiemy na pewno, że tylko z niej będą wysyłane listy. smtpd_client_restrictions = reject_unknown_client, permit pozwala wysyłać wszystkim, o ile ich IP mają wpisy w DNSie. Nie pamiętam dokładnie, ale nie pozwoli chyba wysyłać listów z LAN (potrzebny na początku permit_mynetworks aby LAN przepuścił). UWAGA: po każdorazowej zmianie ograniczeń, należy upewnić się, sprawdzić czy działają one w sposób taki, jaki chcemy. Często osiągniemy zablokowanie nie tylko nieproszonych gości, ale także siebie lub nasze komputery z LAN. Weźmy pod uwagę wszystkie możliwości, jakie mogą się zdarzyć, żeby nie narobić więcej szkody, niż pożytku ! |
| 11b. na podstawie adresu nadawcy listu |
W tym przypadku nie jest brany pod uwagę adres IP kompa łączącego się z naszym serwerem. Sprawdzane jest pole "list od" (inaczej - "from:"). Zmienna, która jest wykorzystywana w tym przypadku to smtpd_sender_restrictions. Domyślna konfiguracja pozwala wysłać list zawierający jakikolwiek adres nadawcy. Możemy wprowadzić między innymi następujące ograniczenia: * reject_unknown_sender_domain - odrzuca list, jeśli adres nadawcy, dokładnie część po @ adresu nadawcy, nie ma wpisu w DNS. Czyli np. list próbuje wysłać heniek@skocz.mi.pajacu :) * reject_non_fqdn_hostname - odrzuca list, jeśli adres nadawcy, dokładnie część po @ adresu nadawcy nie jest "pełna" (fully-qualified domain form). * check_sender_access maptype:mapname - przeszukuje plik podany jako argument. Zawiera on dane co zrobić z tym fantem. Opisane na końcu rozdziału. * permit - pozwól na wysłanie listu. Przydatne na końcu listy ograniczeń, jako zachowanie domyślne, gdy poprzednie reguły nie pasują. * reject - odrzuć list. Przydatne na końcu listy ograniczeń, jako zachowanie domyślne, gdy poprzednie reguły nie pasują. Przykład: smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_hostname Zalecana wartość tego parametru, odrzuca "debilne" adresy nadawcy i jego listy. UWAGA: po każdorazowej zmianie ograniczeń, należy upewnić się, sprawdzić czy działają one w sposób taki, jaki chcemy. Często osiągniemy zablokowanie nie tylko nieproszonych gości, ale także siebie lub nasze komputery z LAN. Uważaj, żeby nie przesadzić. |
| 11c. na podstawie adresu odbiorcy listu |
Tym razem kryterium pozwolić - odrzucić jest adres odbiorcy listu, adres docelowy listu.Zmienna, która jest wykorzystywana w tym przypadku to smtpd_recipient_restrictions. Domyślnie nałożone są pewne ograniczenia, podane w przykładach poniżej. Możemy wprowadzić między innymi następujące ograniczenia: * reject_non_fqdn_recipient - odrzuć list, jeśli podany adres odbiorcy nie jest "pełny" (fully-qualified domain form) * reject_unknown_recipient_domain - odrzuć, jeśli adres docelowy listu, jego adres nie istnieje w DNS (czyli i tak nie ma dokąd go wysłać) * check_recipient_access maptype:mapname - przeszukuje plik podany jako argument i na jego podstawie decyduje czy wysłać list. Opisane na końcu rozdziału. * permit_auth_destination - przyjmij list, jeśli to nasz serwer jest jego celem lub adres przeznaczenia zawiera się w zmiennej $relay_domains. Jeśli warunek nie jest spełniony, bierz pod uwagę następne ograniczenia. * reject_unauth_destination - podobne do poprzedniego, ale odrzuć list, jeśli to nasz serwer nie jest jego przeznaczeniem. Odrzuca list, nie sprawdza innych ograniczeń. * check_relay_domains - jeśli adres IP komputera, który wysyła list pasuje do $relay_domains lub celem listu jest $relay_domains lub to nasz serwer jest komputerem docelowym - przyjmij list, w przeciwnym wypadku go odrzuć i zakończ. * permit - pozwól na wysłanie listu. Przydatne na końcu listy ograniczeń, jako zachowanie domyślne, gdy poprzednie reguły nie pasują. * reject - odrzuć list. Przydatne na końcu listy ograniczeń, jako zachowanie domyślne, gdy poprzednie reguły nie pasują. Przykłady: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination Jest to wartość domyślna ograniczenia. smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_non_fqdn_recipient Nie pozwala wysłać listu do nieistniejących komputerów docelowych. UWAGA: po każdorazowej zmianie ograniczeń, należy upewnić się, sprawdzić czy działają one w sposób taki, jaki chcemy. Jest to szczególnie ważne tutaj, w tej zmiennej. |
| Dodatek: |
check_xxxxx_access maptype:mapname W trzech wymienionych wyżej restrykcjach (smtpd_recipient_restrictions, smtpd_client_restrictions, smtpd_sender_restrictions) istnieje możliwość zdefiniowania swoistej bazy danych - adresów komputerów i userów oraz zachowania się postfixa względem nich. Przykład definicji takiego pliku: smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/odbiorcy Plik taki ma bardzo prostą składnię, mianowicie: user_komp [spacja lub tabulator] co_zrobić Gdzie co_zrobić ma wartość: OK żeby zaakceptować oraz REJECT aby odrzucić. Zmienna user_komp może wyglądać tak: linio@terramail.pl (nie trzba chyba wyjaśniać), terramail.pl (każdy user@terramail.pl), linio@ (user linio na każdym możliwym komputerze). Przykładowy plik odbiorcy może więc wyglądać tak: heniek@ REJECT tomek@costam.pl REJECT poczta.pl OK Plik ten (/etc/postfix/odbiorcy - dla zmiennej check_recipient_access) definiuje do kogo listu nie wysyłać - nie zostanie on wysłany do żadnego heniek@polska.pl, heniek@dupa.pl, heniek@...... itd, ani do tomek@costam.pl, kimkolwiek by ten user nie był. W analogiczny sposób definiujemy te pliki dla check_sender_access - i tam możemy sobie zdefiniować od kogo listu nie przyjąć, smtpd_client_restrictions - gdzie definiujemy np. od jakich komputerów połączenia nie przyjąć i tak jak to zrobiliśmy przed chwilą - check_recipient_access - dla kogo listów nie dostarczać lub dostarczać. Dobra, żeby posfix zaskoczył, należy jeszcze wydać polecenie (jako root): postmap /etc/postfix/odbiorcy i gdy ten zrobi swoje bez błędu (powienien utworzyć /etc/postfix/odbiorcy.db) robimy postfix reload. Należy wiedzieć, że te same prawa możemy ustawić na różne sposoby, jednak najważniejsze jest to, żeby po każdej takiej zmianie sprawdzić czy wszystko działa tak jak powinno. Jeśli nie - szukamy innego sposobu aby odpowiednio zabezpieczyć nasz serwer. Sposoby, które przedstawiłem wyżej mają naprawdę potężne możliwości i możemy całkiem sprytnie z ich pomocą skonfigurować komputer, a nie są to wszystkie możliwości (jest ich za dużo...) Jeszcze jedno: mogłem gdzieś popełnić literówkę - zajrzyj więc od czasu do czasu (szczególnie gdy coś nie gra) do /etc/postfix/sample-smtpd.cf. Ja w każdym razie jestem przekonany, że będziesz miał z nimi niezłą jazdę - będziesz myślał, że wszystko jest o.k. a tu się okaże (znowu), że gdzieś przesadziłeś - ze swojej strony życzę udanej zabawy ;). |
| 12. Wirtualne domeny |
Te "podstawy konfiguracji" powoli zaczynają się zamieniać w "konfigurację"... Dobra. Może na początek: czym są wirtualne domeny? Otóż to, że mamy serwerek i określoną nazwę nie oznacza, że możemy odbierać pocztę tylko dla siebie. Tak, tak... Nasz serwer (nazwijmy go "jeden.pl") może odbierać pocztę także innych komputerów (np. "dwa.pl"). Zastosowanie tego jest chyba oczywiste. Przykład: jeśli nasza znajoma firma ma SDI, a my mamy Polpaka-T, możemy robić im za serwer poczty. Jedyne, co trzeba załatwić, to wpis w DNS, żeby zwracał nasz adres przy zapytaniu o pocztę (o ile pamiętam - rekord MX). Jeśli to czytasz, zakładam że wiesz o co chodzi :). Postfix umożliwia obsługę wirtualnych domen. Dobra, to chyba wiesz. Ale możliwe, że nie wiesz, że umożliwia to na dwa sposoby: są to wirtualne domeny w stylu Postfixa, drugie: wirtualne domeny w stylu Sendmaila. Czym one się różnią - zapytasz. "Styl Postfixa" polega na tym, że każde konto w wirtualnej domenie musi mieć swój wpis. Oznacza to, że jeśli mamy lokalnego użytkownika np. heniek@jeden.pl, to dla wirtualnej domeny dwa.pl nie istnieje użytkownik heniek@dwa.pl. Inaczej: wirtualna domena w stylu Postfixa nie istnieje dla nikogo, dopóki nie utworzymy dla lokalnego użytkownika wpisu, przekierowania. Musisz utworzyć wpis dla każdego użytkownika domeny wirtualnej, napisać do jakiego użytkownika lokalnego ma trafiać jego poczta. Już się pewnie domyślasz, że "Styl Sendmaila" polega na tym, że w momencie utworzenia wirtualnej domeny, automatycznie zaczynają istnieć wszyscy lokalni użytkownicy. Jeśli masz lokalnych userów hyzio, dyzio, zyzio @jeden.pl, automatycznie otrzymują oni swój drugi adres e-mailowy: hyzio, dyzio, zyzio @dwa.pl. "Styl Postfixa" ma tą przewagę, że np. root@jeden.pl trafia do jednej osoby, a root@dwa.pl może trafiać do kogoś innego (np. użytkownika heniek). Tak czy inaczej, wszystko zależy od Ciebie - który rodzaj chcesz zastosować. Jeszcze mała uwaga: "styl Sendmaila" jest dostępny w Postfixie od wersji 20001118. Podsumowując: musisz załatwić jedynie przekierowanie DNS poczty na twój komputer aby za chwilę (dosłownie) wszystko zaczęło działać. Styl wirtualnej domeny wybierz sobie sam - każdy ma swoje wady i zalety, a ich skonfigurowanie Postfixa do ich obsługi jest banalnie proste (zawsze chciałem tak o czymś napisać ;). |
| 12a. Wirtualne domeny w stylu Postfixa |
Dobra. Bierzemy w obroty plik /etc/postfix/main.cf (chyba, że masz gdzieś indziej). JEDYNYM wpisem, który musimy zrobić w tym pliku, jest: virtual_maps = hash:/etc/postfix/virtual Plik, może się nazywać inaczej. Ważna uwaga: NIE zmieniamy w pliku main.cf innych opcji (takich jak: mydestination, myorigin itp.). Jednym wpisem, dotyczącym obsługi wirtualnej domeny w main.cf powinien być ten element. Przynajmniej w stylu Postfixa. Jak się możesz domyślić, zapisujemy zmiany i tworzymy ww. plik, a jeśli on istnieje, poddajemy go edycji. Komentarze tworzy znak # (hash). Naszą domeną wirtualną niech będzie: dwa.pl. Obowiązkowo, w stylu Postfixa, na początku tego pliku musi być wpis (pierwsza linijka): [wirtualna_domena cokolwiek] gdzie cokolwiek oznacza jakikolwiek wpis, naprawdę, byle co. W naszym przypadku: dwa.pl yeahh_baby Widać, że "yeahh_baby" jest czymkolwiek :) Teraz możemy sobie normalnie definiować użytkowników domen wirtualnych. Poniżej przykład, gdzie poczta dla uzytkownika wirtualnego: czesiek trafia do użytkownika: heniek, poczta dla wujek idzie do cioci, poczta dla billa idzie do kosza a poczta dla roota wirtualnej domeny idzie do jozefa. dwa.pl yeahh_baby czesiek@dwa.pl heniek wujek@dwa.pl ciocia bill@dwa.pl kosz conan@dwa.pl conan root@dwa.pl jozef Nie muszę chyba wyjaśniać, że lokalni użytkownicy to ciocia, heniek, kosz, jozef i conan. Inni lokalni użytkownicy nie mają adresu w wirtualnej domenie. Acha, między adresem "wirtualnym" a lokalnym użytkownikiem nie ma dwukropka, tylko spacja, tabulator itp. Dobra, zapisujemy plik. Pozostało wydać komendę: postmap /etc/postfix/virtual a następnie przeładować Postfixa: postfix reload. I to wszystko ! |
| 12b. Wirtualne domeny w stylu Sendmaila |
Na początek wrzucamy do edytora plik "main.cf". Tam dopisujemy: virtual_maps = hash:/etc/postfix/virtual oraz obowiązkowo dopisujemy do zmiennej $mydestination nazwę naszej wirtualnej domeny: $mydestination = $myhostname,......., dwa.pl W tym przypadku dopisaliśmy "dwa.pl". Oczywiście tworzymy jesli nie istnieje, lub edytujemy plik "virtual". NIE dajemy na jego początku wpisu, jak w przypadku stylu Postfixa, "dwa.pl cokolwiek". Nasz plik virtual, może wyglądać tak: czesiek@dwa.pl heniek wujek@dwa.pl ciocia Tutaj chyba nie muszę wyjaśniać, że poczta do wujka "wirtualnego" trafia do cioci (użytkownik lokalny) a bill do kosza. Poza tym, każdy użytkownik lokalny automatycznie dostaje swój drugi adres e-mailowy. Adres wirtualny. Jeśli mamy użytkownika hyzio, od tej pory ma on dwa adresy: hyzio@jeden.pl i hyzio@dwa.pl Na tym właśnie polega "styl Sendmaila". Między adresem "wirtualnym" a lokalnym użytkownikiem nie ma dwukropka, tylko spacja, tabulator itp. Zapisujemy plik, wydajemy polecenie postmap /etc/postfix/virtual i przeładowujemy Postfixa:postfix reload. Prawdę mówiąc - w zasadzie - pisząc - to by było na tyle. |
| 13. Powiadamianie na komórkę (Plus GSM) |
Tak się składa, że tylko Plus GSM nie komplikuje życia swoim abonentom. I to się chwali, jednak ceny mogliby trochę obiżyć :). Do rzeczy: każdy posiadacz telefonu w Plusie (dotyczy także SimPlusa) posiada adres emailowy następującej postaci: nr_telefonu@text.plusgsm.pl. Nie muszę chyba dodawać, że każda wiadomość trafiająca pod ten adres, jest wysyłana jako SMS do telefonu. Źli chłopcy wykorzystują to w niecnym celu, my jednak zrobimy z tego pożytek. A pożytek wygląda tak: dostajemy na serwer nowy list, Postfix go przyjmuje i umieszcza w skrzynce a przy okazji wysyła SMSa do odpowiedniej osoby o treści: "Nowy list na koncie heniek@serwer.pl", dorzuca do tego SMSa jeszcze temat listu oraz jego nadawcę. Sposób który zaraz przedstawię nie jest może najlepszym rozwiązaniem tej sprawy, ale na pewno działa. SMS jest wysłany od razu po odebraniu poczty, a na telefon przybywa, w zależności od obciążenia serwera Plusa: od jednej sekundy do kilku minut po nadejściu imejla. Będziemy potrzebować programu o nazwie procmail. Prawdopodobnie masz go na dysku w katalogu "/usr/bin", sprawdź to poleceniem "which procmail". Jeśli go nie masz (w co nie wierzę), pobierz go ze strony http://www.procmail.org. Może teraz dwa słowa co to właściwie jest. Procmail jest "przerabiaczem poczty". To, moim zdaniem, najlepsze określenie tego, co potrafi ten program. Niech to wystarczy :) Jeszcze będziemy potrzebować programik o nazwie formail, ale ten prawdopodobnie jest jednym z elementów procmaila. Standardowo w "/usr/bin". Bierzemy się do roboty, bo powoli robi się ciemno ;) Może jeszcze jedno: proszę nie przysyłać mi pytań dotyczących procmaila, ponieważ nie znam tego programu. Jak będziesz potrzebował jakichś info, czytaj dokumentacje i wysyłaj posty na grupy dyskusyjne. Ja tak właśnie robię. Zaczynamy: W katalogu /etc/ utwórz plik procmailrc. Jest to główny, domyślny plik konfiguracyjny tego programu. Proponuję umieścić tam następującą treść: VERBOSE=on SHELL=/bin/sh PMDIR=/etc/procmail/$LOGNAME LOGFILE=$PMDIR/procmail.log INCLUDERC=$PMDIR/general.rc ORGMAIL=/var/spool/mail/$LOGNAME MAILDIR=$HOME PROCMAIL_VERSION=666 Teraz po kolei: VERBOSE - oznacza żeby logował to, co czyni. Dobra rzecz. SHELL - to shell. Nie sprawdzałem z innymi, niż /bin/sh. Jak chcesz się w to pobawić - proszę bardzo. PMDIR - to katalog konfiguracyjny dla każdego usera. LOGFILE - tutaj zapisuje co robi. Ponieważ każdy user ma swój PMDIR, łatwo czytamy co się dzieje dla każdego usera. INCLUDERC - to będzie główny plik konfiguracyjny, z formatowaniem SMSa, nr telefonu itp. ORGMAIL - czyli gdzie przechowywana jest poczta po przybyciu. MAILDIR - hmm... PROCMAIL_VERSION - wpisz tam jakieś bzdury, gdyby ktoś próbował się za dużo dowiedzieć. Jak już pewnie zauważyłeś, w katalogu /etc/procmail/ (już czas go utworzyć) będzą przechowywane pliki konfiguracyjne i pliki z logami i cała reszta. Każdy user będzie miał swój katalog, np. /etc/procmail/heniek, /etc/procmail/jojo itd. Jeśli nie odpowiada tobie położenie tego katalogu - zmień sobie ścieżkę. I wszystkie inne konsekwentnie. Dobra, pozostało naprawdę niewiele teraz. Ja będę eksperymentował na użytkowniku "heniek", który ma komórkę w Plusie o numerze (+48) 603 123456. Przepraszam, osobę do której należy ten numer :) Tworzymy katalog /etc/procmail/. I kolejny: /etc/procmail/heniek/ Pamiętaj, że mam usera heniek@serwer.pl. Od tej pory używam Heńka (żadnych głupich skojarzeń) a Ty odpowiednio go sobie zmieniaj. Pozostało tylko utworzyć odpowiedni plik w katalogu /etc/procmail/heniek/. Jeśli cofniesz się parę linijek wyżej powinieneś wyczaić, że ten plik to (zmienna INCLUDERC): general.rc. Tak więc tworzymy tam sobie taki plik. A jego treść ? Dla użytkownika heniek@moj.serwer.pl z nr telefonu: 603123456 wygląda tak: :0 c * ^From* | formail -X Subject: -X From: |mail -s "Nowy email na koncie" 48603123456@text.plusgsm.pl Należy uważać na znaczki, dlatego teraz słownie: dwukropek zero [spacja] ce (pierwsza linia), gwiazdka [spacja] "górny daszek" From gwiazdka(druga linia), "pionowa kreska" - jak ta przy tworzeniu potoków - [spacja] minus dużyIks spacja... a dalej to już widzisz. Ale błazenada. Pamiętaj tutaj o dużych literach przy Subject i From, i o tym, że po tych wyrazach są dwukropki. Ważne: nie stawiaj plusa (+) przed numerem telefonu bo SMS nie dojdzie. To i tyle... prawie tyle. Jeszcze jeden szczegół. Co robi general.rc: każdy list który wpada, od kogokolwiek, jest obrabiany tak: wytnij z niego temat (Subject) i nadawce (From) i razem z "Nowy email na koncie" wyślij to wszystko (docelowo dojdzie jako SMS) na podany adres emailowy (ten z nr telefonu). Tia. Jeszcze jedna ważna rzecz. W sumie najważniejsza, bo bez tego ani rusz: należy powiedzieć Postfixowi, żeby zaczął używać procmaila. Tradycyjnie: wrzucamy do edytora plik /etc/postfix/main.cf i tam szukamy zmiennej mailbox_command. Jeśli takowej nie ma, sami sobie tworzymy i robimy taki wpis: mailbox_command = /usr/bin/procmail Ścieżkę możesz mieć inną, ale o tym wiesz. Dobra, teraz: postfix reload i szafa gra. A przynajmniej powinna grać :) A wszystko działa tak: postfix przyjmuje maila do henka. Widzi, że trzeba użyć procmaila. A więc go uruchamia. Procmail czyta /etc/procmailrc i widzi, żeby coś zrobił. A co ? A to, co jest w /etc/procmail/heniek/general.rc. Tak więc procmail to robi i bez względu na to, czy mu się uda czy też nie wynik swojej działalności zapisuje w /etc/procmail/heniek/procmail.log a następnie kończy pracę. W tym czasie Postfix zdążył już odłożyć świeżą pocztę do odpowiedniego katalogu i wszyscy są szczęśliwi. Teraz na poważnie: nie jestem specjalistą od procmaila i zdaję sobie sprawę z tego, że pewne rzeczy tutaj są nadmiarowe. Jeśli wiesz, jak można to wszystko uprościć, przyślij mi imejla. Wskazówka dla Ciebie: pewnie nie możesz doczekać się już SMSa :) Żeby się upenić czy wszystko poszło ok zobacz do pliku z logami: /etc/procmail/twoj_login/procmail.log. Kolejna wskazówka: plik general.rc napisz tylko raz, a dla kolejnych userów skopiuj go w odpowiednie miejsce, zmieniając tylko nr telefonu. |
| 14. Powiadamianie na GaduGadu |
Paweł Pałka jest autorem programu GateGaduDeamon (ggdaemon) do informowania o nowych mailach na odpowiedni numer GG. Wszystkie informacje na temat softu można znaleźć na jego stronie domowej: http://rex.olsnet.eu.org |
| 15. Postfix + MKS vir |
O ochronie antywirusowej wiele już powiedziano i nie mam zamiaru dodawać nic od siebie. Może tylko tyle: administrator musi czasami myśleć za użytkowników. Od pewnego czasu firma Mks vir udostępnia swój program antywirusowy (jeden z najlepszych jakie znam) także na Linuxa. I robi to z klasą: używanie programu pod tym systemem nic nie kosztuje. Tak trzymać ! Program ten jest ciągle w (intensywnej) wersji rozwojowej. Trwają prace nad jego demonizacją, współpracą z Amavisem i kilkoma innymi pozytywnymi rzeczami. Dla chłopaków pracujących nad tym składam wielkie DZIĘKI. Sposób, który tutaj opisuje uruchamia mksa przez procmaila. Ma to kilka istotnych wad, z których najważniejszą jest spore obciążenie procesora. Warto, abyś to wiedział. Odsyłam do dokumentacji dostarczonej razem z Mksem. Można wyczytać tam kilka ciekawych rzeczy, linków itp. Do rzeczy: program można pobrać ze strony mksa: http://linux.mks.com.pl. Jeśli link nie będzie działał, poszukaj softu przez stronę główną Do tego, co opisuję, wystarczy pobrać plik mkslinux.tgz. O ile jego nazwa się nie zmieni :) Testowałem to wszystko na wersji 1.3beta Instalacja (w skrócie, może się zmienić w następnej wersji programu). a) rozpakowujesz kod źródłowy, wchodzisz do środka b) tworzysz jakiś katalog (np. /usr/local/mks/) i wszystko tam przerzucasz c) wchodzisz do tego katalogu i czytasz dokumentację... d) domyślny plik konfiguracyjny to /etc/mks_vir: cp mks.cfg /etc/mks_vir.cfg e) edytujesz tak powstały /etc/mks_vir.cfg i odhaszowujesz to: --mks-vir-dat-path=/usr/local/mks/ ważny slesz na samym końcu katalogu i właściwa ścieżka do niego --scan możesz wybrać sobie coś innego, tylko wiedz CO wybierasz Zapisujesz zmiany. f) tworzysz link symboliczny do pliku mks32, np. tak: ln -s /usr/local/mks/mks32 /usr/local/bin/mks32 g) Teraz możesz sprawdzić, czy program działa, np. tak: mks32 nazwa_jakiegoś_pliku Powinieneś zobaczyć kilka ciekawych linijek wyjściowych. Jeszcze raz zachęcam do czytania dokumentów dostarczonych z mks'em - są po polsku :) Teraz powinieneś mieć działającego mksa. Na zwykłych plikach, przetestuj go z wirusami, poczytaj jak aktualizować jego bazę danych wirusów i takie tam. Bierzemy się za Postfixa. Jak napisałem wcześniej, będzie on wywoływał mksa przez procmaila. Dla wszyskich użytkowników, niezależnie od ich woli. Jeszcze jedna uwaga: jak już pewnie się domyśliłeś skanowana będzie tylko poczta przychodząca do użytkowników. Dobra: na początek musisz mieć działającego procmaila, uruchamianego przez Postfixa, gdy przychodzi poczta. Opisałem to wyżej, przy okazji powiadamiania SMSem o nowej poczcie. W skrócie: a) w main.cf masz wpis: mailbox_command=/usr/bin/procmail chyba że u Ciebie znajduje się on w innym miejscu. b) plik /etc/procmailrc to główny plik konfiguracyjny procmaila. Wystarczy, że w jego zmiennych masz: SHELL=/bin/sh i na końcu, po innych zmiennych w stylu VERBOSE, MAILDIR itp. umieszczasz czarodziejskie linijki: :0 * | mks32 -e 1>>$ORGMAIL 2>>/var/log/mks.log Słownie: dwukropek zero [Enter] gwiazdka [Enter] "pipe" mks32... Musisz jeszcze utworzyć plik z logami (/var/log/mks.log) i dać wszyskim użytkownikom prawa do jego zapisu. Procmail działa jako user i musi mieć możliwość zapisu do logów. Zrób to, przynajmniej na początku, żeby widzieć czy jest o.k., czy skanuje pocztę. Potem możesz logi przekierować do /dev/null jeśli nie chcesz ich oglądać. Chociaż warto wiedzieć, co się tam dzieje... A jeśli nie będzie odpowiednich praw do logów, mks32 położy laskę na skanowanie i puści plik z wirusem. To wszystko, testuj ! Jeszcze raz zaznaczam, że to wersja rozwojowa i często się zmienia. Mks przysyła fajny komunikat, gdy znajdzie wirusa. Gdy będzie można fajnie połączyć go z Amavisem, napiszę o tym. Pamiętaj, żeby uaktualniać bazę danych wirusów w miarę często. Jak coś nie gra, CZYTAJ LOGI. Logi dla procmaila możesz utworzyć przez taką zmienną (w /etc/procmailrc): LOGFILE=$HOME/procmail.log w katalogu domowym usera, do którego przychodzi poczta będzie zapisywał co jest grane... |
| 16. Statystyki dla Postfixa |
Ten fragment pisany jest bez polskich literek. Dobra, zacznijmy od poczatku. Kazdy chyba wie, co to sa statystyki. Bardzo dobrze sprawdzaja sie one wtedy, gdy przez nas serwer przechodzi stosunkowo duzo poczty. Od logow az oczy bola... Po pierwsze, musisz wiedziec gdzie Postfix zapisuje swoje logi. U mnie jest to plik /var/adm/mail_in.log. Nie musze chyba przypominac, ze takie rzeczy ustawia sie w pliku /etc/syslog.conf (np. mail.* /var/adm/mail_in.log). Jesli tam spojrzysz, zobaczysz calkiem spory bajzel. Oczywiscie po chwili sie polapiesz co, skad, od kogo i do kogo zostalo wyslane. Czy nie byloby prosciej, gdybys dostal to wszystko od razu na tacy ? Znalazlem w Sieci bardzo fajny program, napisany w Perlu. Nazywa sie on pflogsumm.pl i mozna go pobrac, oraz poczytac o nim tutaj. W chwili gdy to pisze, aktualna, stablina wersja to 0.9. Oprocz tego, bedziemy potrzbowali oczywiscie Perla (wersja chyba 5.003 przynajmniej) oraz modulu dla niego Date::Calc, ktory mozna sobie sciagnac z www.cpan.org lub z jakiegos jego mirrora. Jesli masz Perla, sciagasz sobie Date::Calc (Date-Calc) i po rozpakowaniu wchodzisz do jego katalogu oraz wydajesz komende: perl Makefile.PL make make test make install Zakladam, ze wszystko poszlo dobrze, bo nie o Perlu tutaj chce pisac. W razie klopotow, rzuc okiem do pliku Install.txt. Okey, mamy Perla, Date::Calc udalo sie dorzucic do niego, pozostal nasz pflogsumm.pl. Jest to plik tekstowy (to dla tych, ktorzy nie wiedza), patrzymy na jego poczatek (poleceniem np. head pflogsumm.pl) i patrzymy czy sciezka do perla zgadza sie z nasza sciezka (which perl) i jak nie, to zmieniamy ja w tym pliku. Plik programu musi byc oczywiscie wykonywalny (atrybut x) a osoba ktora go wywoluje musi miec oczywiscie prawa do czytania logow :) Pokaze tutaj wywolanie programu tak, jak ja go uzywam. Nie jest on niebezpieczny i proponuje samemu sie pobawic w inne jego opcje. Zasada wywolania jest taka ./pflogsum.pl -d [dzien] [sciezka do pliku] Ja wywoluje go dodatkowo z opcja -e (chyba od extended) i w sumie mam tak: ./pflogsum.pl -e -d yesterday /var/adm/mail_in.log Czyli program wypisze mi rozszerzone (-e) statystyki poczty z wczoraj (-d yesterday) a dane bedzie bral z pliku /var/adm/mail_in.log. Teraz czas na zlozenie wszystkiego do kupy. Jest godzina czwarta w nocy, userzy dawno spia, a na serwie z crona wywolane jest codziennie: pflogsum.pl -e -d yesterday /var/adm/mail_in.log | mail -s "Statystyka wczorajszej poczty" admin@localhost Czy to nie fajne ? Codziennie rano czeka na mnie w skrzynce list ze statystyka wczorajszej poczty. Program pflogsumm bardzo fajnie ja przedstawia z opcja -e. Tak wiec rano loguje sie, biore lyka kawy, wlaczam pine, zapalam papierosa i czytam sobie statysyke poczty... co i Tobie polecam. |
| 17. Oczekując na błąd |
Sprawa wygląda tak: ktoś łączy się przez telnet z portem 25 serwera poczty i zaczyna wpisywać dziwne komendy zaczerpnięte z hakierskich FAQ. To nic że dotyczą one Sendmaila, to nic że Sendmaila wersji 0.09, to nic że Postfixowi taki hakier może naskoczyć. Każdego normalnego admina takie zagrywki po prostu denerwują. Po wpisaniu takiej debilnej komendy po pewnym czasie zwracany jest błąd, kolejny błąd, kolejny... w końcu serwer zamyka połączenie mówiąc dzieciakowi "na drzewo !". Aby zniechęcić amatorstwo do takiej zabawy możemy wydłużyć czas zwrócenia komunikatu o błędzie oraz przyspieszyć rozłączenie. smtpd_error_sleep_time - definiuje czas w sekundach, po którym zwracany jest komunikat o błędzie. Domyślnie ma wartość 5 (sekund). Nie ma co w tym miejscu przesadzać, ponieważ z założenia ma on chronić normalnych użytkowników poczty, których "prymitywne" klieci poczty mogą wpaść w pętle: połącz - wyślij - rozłącz. Na skutek błędu oczywista, gdy nie zostanie wysłana poczta, programy kliencie mogą na upartego znowu się łączyć i próbować wysłać to samo. Tak więc opcja ta dotyczy zarówno "telnetowców - kombinatorów", jak i normalnych użytkowników, którzy mogą czekać na komunikat o błędzie wieczność. Domyślne pięć sekund wydaje się być tutaj całkiem sensowną wartością. Zmiana na trzy sekundy: smtpd_error_sleep_time = 3 smtpd_soft_error_limit to bardzo ciekawy parametr. Domyślnie ma on wartość 10, co oznacza, że po przekroczeniu 10 błędów w czasie jednego połączenia, komunikat o błędzie zwracany jest po liczbie błędów sekund. Jaśniej: gdy w czasie jednego połączenia, wystąpi 10 błędów, komunikat o błędzie zwracany jest co 5 sekund (dokładniej: co smtpd_error_sleep_time sekund). Gdy wystąpi 11 raz, komunikat o błędzie pojawi się po 11 sekundach, gdy błąd wystąpi 12 raz, komunikat o błędzie pojawi się po 12 sekundach i tak dalej. Ponieważ wystąpnienie więcej niż 3 błędów w czasie jednego połączenia jest raczej nienormalne dlatego wartość tą można ustawić np. na 3. Czwarty błąd zostanie zwrócony po 4 sekundach, 5 po pięciu itd.: smtpd_soft_error_limit = 3 smtpd_hard_error_limit - domyślna wartość to 100. Definiuje on po ilu błędach połączenie zostanie przerwane. Nic dodać, nic ująć. Jeśli ktoś nie chce się bawić w smtpd_soft_error_limit, może od razu ustawić tą wartość na np. 5. Nie należy przesadzać, ponieważ czasy i błędy ww. dotyczą także zwykłych, nieświadomych użytkowników, których klienci poczty są niewłaściwie skonfigurowane, przestarzałe a na linii dochodzi do zakłóceń. Przykład, gdy po 5 błędach połączenie jest zamknięte: smtpd_hard_error_limit = 5 Zasada jest taka: czasy i liczby do ww. parametrów ustalaj w podanej wyżej kolejności, uważaj żeby nie przesadzić. Należy pamiętać, że 2-3 błędy mogą przydarzyć się normalnym użytkownikom, powyżej nich można albo bawić się w opóźnianie albo szybko zamknąć połączenie i pozbyć się buraka. |
| 18. Jaki serwer ? |
Jest wielce prawdopodobne, że będziesz chciał ukryć nazwę i wersję swojego serwera poczty przed innymi. Oto kilka wskazówek: * Serwer poczty działa standardowo na 25 porcie. Po wydaniu polecenia telnet localhost 25 zobaczymy dane naszego programu pocztowego. O ile my to wiemy bez telnetu, to dobrze by było gdyby inni tego nie widzieli. Komunikat, który jest wyświetlany po połączeniu z serwerem poczty, można zmienić, wpisując do pliku main.cf zmienną smtpd_banner i nadając mu odpowiednią wartość. Proponuję: smtpd_banner = $hostname ESMTP * Jeśli ktoś otrzyma pocztę z naszego serwera, to i tak w nagłówku znajdzie "Postfix". Jak to zmienić ? Służy do tego parametr mail_name. Po zmianie jego wartości, w nagłówku listu pojawi się ten właśnie serwer. Czyli: mail_name = Microsoft ShittyServer 2.6 Teraz to wszystko funkcjonuje całkiem przyzwoicie. Zawodowcy Twój serwer poczty sprawdziliby wysyłając list do użytkownika, który nie istnieje. Dostaliby odpowiedź: "This is the Microsoft ShittyServer 2.6 at ....". Fajnie, ale w części drugiej tego listu pojawiłaby się sekcja: Diagnostic-Code: X-Postfix;..... Jedynym rozwiązaniem tego problemu, z tego co mi wiadomo, jest zmiana kawałka kodu w pliku /ścieżka/do_kodu/źródłowego/src/bounce/bounce_notify_util.c W tymże pliku na sztywno jest zdefiniowny X-Postfix. Albo należy wyciąć ten fragment albo zmienić go np. na X-Qmail. Po kompilacji i ponownej instalacji programu nie otrzymamy już tego fragmentu (lub otrzymamy zmieniony :). Może to spowodować sytuację, w której użytkownik - hakier spotyka nas i mówi: "Ale ty ich robisz w wała. Myślą, że masz serwer Micro$oftu ale ja i tak wiem, że masz Qmaila". Oczywiście możemy go pochwalić: "Skąd o tym wiesz ?". A co, niech ma coś od życia... Zmiana kodu źródłowego to już wyższa szkoła jazdy, nie wiem czy przy okazji nie ingeruje ona w zasady licencjonowania programu (zmiana kodu i takie tam). Tak czy siak, zabawa jest fajna... |
| 19. Inne |
* Razem z postfixem dostarczany jest taki fajny programik: postsuper. Ta na co ? Ano służy on okresowemu sprawdzaniu naszego serwera poczty tj. sprawdza jego strukture, kasuje niepotrzebne już pliki i w ogóle robi porządki. Aby to uczynił należy (jako root) wydać polecenie postsuper -s -p. Najlepiej wrzucić to sobie do crona (u mnie raz na 24h). Kolejnym ciekawym zastosowaniem postsuper jest możliwość usuwania wysłanych a nie dostarczonych maili (czyli takich, które są w kolejce i nie opuściły jeszcze serwera): postsuper -d [ID listu] postsuper -d ALL Oczywiście drugie polecenie usuwa wszystkie listy z kolejki. Pierwsze natomiast list o konkretnym ID (polecenie mailq przychodzi tu z pomocą). THX dla Macieja M. z SEB TFI S.A. * Ciekawym parametrem jest maksymalny rozmiar wiadomości, jaki nasz serwer może przyjąć (razem z załącznikiem). Wielkość tą ustawiamy wpisując do pliku main.cf parameter message_size_limit oraz podając ową wielkość w bajtach. Przykładowo, ustawmy ją na ok. 5MB: message_size_limit = 5000000 * Inny parametr - mailbox_size_limit - pozwala ustawić ilość miejsca na wszystkie listy użytkownika, czyli pojemność skrzynki pocztowej. Jest to swojego rodzaju "quota" skrzynki pocztowej userów. Podawana jest (żeby skomplikować życie) w bajtach, a jej domyślna wielkość to 50MB (czyli 51200000). Aby to zmienić na np. 100MB wpisujemy: mailbox_size_limit = 102400000 * Jeśli nasze listy obrabiane są przez procmail, należy w pliku /etc/postfix/main.cf wprowadzić zmienną mailbox_command i nadać jej warość procmaila (wraz ze ścieżką dostępu). Czyli: mailbox_command = /usr/bin/procmail * Opcja smtpd_recipient_limit określa maksymalną liczbę odbiorców jednego listu. Często userzy wysyłają ten sam list (np. z kawałami lub dużymi załącznikami) do wielu osób na raz. Wykorzystują oczywiście pola CC i BCC swojego klienta pocztowego. Domyślnie zmienna ta ma wartość 1000, co może być w całości wykorzystane tylko przez spamerów. Sensowną wydaje się być wartość np. 50, a więc: smtpd_recipient_limit = 50 * "Nie wytrzymam, permanentna inwigilacja" czyli always_bcc. Ta opcja z olei określa adresata, do którego zostanie wysłana kopia każdego listu przesłanego przez postfixa. Innymi słowy, każdy list - czy wychodzący, czy przychodzący przez nasz serwer - zostanie wysłany nie tylko do właściwego odbiorcy, ale także pod zdefiniowany przez nas adres. Pamiętaj, aby szanować prywatność swoich userów... Tak czy siak, aby kopia każdego listu przechodzącego przez nasz serwer trafiła do czesiu@uop.pl należy dopisać: always_bcc = czesiu@uop.pl * "Stary, nie świruj", czyli queue_minfree. Jednym z nielicznych przypadków, kiedy Linux zaczyna wariować, jest brak miejsca na dysku - którejś z używanych przez system partycji. Taką jest np. /var/spool/. Tam też przeważnie wrzucana jest nowa poczta. Aby uniemożliwić postfixowi zapełnienie partycji, do której wrzuca on pocztę, można zdefiniować ilość wolnego miejsca na dysku, którego postfix nie może przekroczyć. Inaczej: dopóki miejsca jest więcej niż queue_minfree postfix dostarcza pocztę. Jeśli tego miejsca jest mniej, postfix odmawia przyjęcia nowej poczty dla użytkownika oraz informuje o tym odpowiednią osobę (domyślnie informuje o tym postmastera). Domyślnie ta opcja ta jest wyłączona, co oznacza, że postfix może zapachać nową pocztą całą partycję. Dobra, aby zostawić minimalnie ok. 10MB wolnego miejsca należy wpisać (jednostką są bajty): queue_minfree = 10000000 * Opróżnić kolejkę... Czasem bywa tak, że zdalny, docelowy serwer do poczty nie odpowiada (chodzi pod Window$em i się zawiesił), nie można do niego dotrzeć (TPsa znowu daje dupy) lub już go nie ma (zwolnili admina z roboty, więc on im położył pocztę). Gdy Postfix nie może dostarczyć poczty, kolejkuje ją u siebie i co jakiś czas sprawdza, czy zdalny się nie pojawił. Tylko co jaki czas i kiedy zwaraca do nadawcy listu informację, że nie może dostarczyć poczty ? Otóż odpowiednio: queue_run_delay oraz maximal_queue_lifetime. Standardowo jest to 1000 sekund dla pierwszego i 5 dni dla drugiego. Jednostki tych opcji to s (sekundy), m (minuty), h (godziny), d (dni) oraz w (tygodnie). Przykładzik: spradzaj zdalnego co pół godziny i zwracaj błąd do nadawcy po trzech dniach: queue_run_delay = 30m maximal_queue_lifetime = 3d * Poczta w sieci lokalnej Gdy w Twojej domowej sieci zainstalujesz 2 serwery poczty, pewnie chciałbyś sobie przesyłać między nimi pocztę, eksperymentować, poznawać Postfixa... Wystarczy wtedy odpowiedni wpis w /etc/hosts, zmiana paru linijek w main.cf i... ignore_mx_lookup_error. Tak jest, Postfix nie dostarczy poczty, dopóki nie otrzma z DNSu rekordu MX (poczta) dla zdalnego serwera. Najlepszym objawem tego jest taki zapis w logach: Name service error for: ...... Host not found, try again. Przypomnę tylko, że nie należy włączać tej opcji, gdy nasz Postfix jest normalnym serwerem poczty w Internecie dla jakiejś domeny.... ignore_mx_lookup_error = yes * Głupi "błąd" Gdy nasz Postfix działa dobrze, ba: wzorowo, w logach może pojawiać się coś takiego: NIS domain name not set - NIS lookups disabled. Pewnie i tak nie korzystasz z NIS, ale Postfix domyślnie zakłada, że to robisz. I nie przekonasz wała, że nie, dopóki nie użyjesz alias_maps. Sęk tkwi w tym, że jedną z wartości tego parametru jest nis:mail.aliases, gdy w przypadku braku NIS wystarczy $alias_database : alias_maps = $alias_database * Kolekcjoner spamu Jeśli chciałbyś przechwytywać całą pocztę przychodzącą dla użytkowników, którzy w systemie nie istnieją, powinieneś skorzystać z parametru luser_relay. Możesz w ten sposób wyczajać spamerów i zapobiec odbijaniu poczty z interesującymi danymi w nagłówkach. Dużym minusem jest fakt, że jeśli osoba z zewnątrz popełniła literówkę w adresie odbiorcy - nie dowie się o tym, że list nie dotarł do adresata. Przykład: luser_relay = czesiek luser_relay = czesiek@brzeszczot.pl * Bramka pocztowa Jeśli całą pocztę wychodzącą z naszego serwerka chcemy wysyłać za pośrednictwem innego serwa (takiego, na którym np. działa program antywirusowy lub np. nasz jest blokowany na firewallu) powinniśmy użyć relayhost. Wówczas każdy email wychodzący z naszego komputera przekazywany jest właśnie do niego: relayhost = antywirus.firma.pl * Ukryć wafli Mamy serwer poczty dla określonej domen(y), np. firma.pl. Jest w niej kilka serwerów pocztowych, ludzie różnie konfigurują Outlooki :). Jeśli chcemy, żeby każdy email wychodzący z naszego kompa miał w adresie nadawcy po "małpce" określony adres, np. firma.pl a nie mail.firma.pl lub poczta.firma.pl wykorzystujemy: masquerade_domains = firma.pl Wszystkie farmazony za "małpą" podane przez użytkowników zostaną zastąpione przez naszą domenę główną. Jeśli dopuszczamy tylko mail.firma.pl i firma.pl: masquerade_domains = mail.firma.pl firma.pl W tym przypadku mail.firma.pl jest przepuszczona przez nasz serwerek, natomiast wszystkie inne domeny (np. poczta.firma.pl) są zamienione na firma.pl. Pojawia się w tym momencie pewien problem. Jak w takiej sytuacji odróżnić wiadomośći które pochodzą od admin@mail1.firma.pl od tych, pochodzących od admin@mail2.firma.pl, które przychodzą do nas ? Komu odpisać, skoro w skrzynce zobaczymy admin@firma.pl ? Ano skorzystać opcji, która definiuje loginy użytkowników dla których maskowanie domen jest pomijane. Na przykład tak: masquerade_exceptions = admin, root * Co w kolejce siedzi ? Polecenie mailq pokaże nam kolejke. BTW: ten sam wynik zwróci postqueue -p. Wiemy więc, co czeka na wysłanie. Gdy jednak spojrzysz do pliku z wiadomością (/var/spool/postfix/......) zobaczysz co ? Śmieci. Żeby odczytać skolejkowaną wiadomość, posłuż się poleceniem postcat. Na przykład tak: postcat /var/spool/postfix/deferred/0/0/004BB2C024 |more Dobre rady wujka Heńka: * Sprawdzajcie co jakiś czas skolejkowaną pocztę (mailq), czytajcie logi generowane przez postfixa. * Nie zmieniajcie na raz wielu opcji. Zmieńcie jedną, zapiszcie zmiany i sprawdźcie czy wszystko działa jak należy. Róbcie kopie zapasowe plików konfiguracyjnych !!! * Na mojej stronie znajduje się opis jak skonfigurować Postfixa z SASL'em. Jeśli jesteś zainteresowany - zapraszam. |
| 20. Postfix + TLS |
Ten punkt powinien być o wiele wyżej, ale nie chce pogubić się w linkach na stronie... Jak wszyscy wiemy, komunikacja na drodze klient - serwerSMTP (Outlook - Postfix :) nie jest szyfrowana. Jest to norma. Gdy pojawia się autoryzacja przy wysyłaniu poczty, także hasło juzera leci otwartym tekstem (w większości przypadków). Może wypadałoby wprowadzić szyfrowanko ? Takie w tle, na wzór SSH zastępującego telnet. Rozwiązanie takie istnieje i nazywa się TLS (ang. Transportation Layer Security) - czyli SSL na SMTP. Może z powodzeniem zastąpić tunelowanie poczty wychodzącej (od klientów- Outlook itp.). Mniejsza z tym, ważne że jest i działa. Aby poprawnie toto zainstalować należy znać a) wersję Postfixa, b) wersję OpenSSL. Nasz TLS dostępny jest jako patch nakładany oczywiście na źródełka Postifxa. Dla każdej nowej wersji Postfixa wychodzi nowy pacz napisany pod konkretną, ostatnią wersję OpenSSLa. Chce powiedzieć, że musisz mieć odpowiedniego Postfixa i OpenSSLa lub apgrejdować któreś z nich. Najlepiej od razu wejdź pod adres i pobierz aktualną wersję softu: http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_ tls/ W chwili gdy pisałem ten punkt, aktualnymi wersjami były: postfix-2.1.3 oraz openssl-0.9.7d. Patch nazywa się więc: pfixtls-0.8.18-2.1.3-0.9.7d.tar.gz. Mamy więc: pfixtls-wersja_pacza-wersja_postfixa-wersja_openssl.tar.gz. Jedna ważna rzecz: zakładam, że OpenSSL został zainstalowany w /usr/local/ssl. Jeśli masz go gdzieś indziej - musisz odpowiednio zmieniać ścieżki, szukać pliki itp. Być może będziesz musiał coś apgrejdować. Okej, przechodzimy do sedna. Zakładam, że mamy zainstalowane OpenSSL, rozpakowane źródełka postfixa i patcha. Wchodzimy do katalogu z Postfixem i wydajemy polecenie: cd postfix-2.1.3/ patch -p1 < ../pfixtls-0.8.18-2.1.3-0.9.7d/pfixtls.diff Powinieneś zobaczyć serię komunikatów w stylu "patching file .....". Dobra, jedziemy dalej. Dalej jest kompilacja Postfixa: make makefiles CCARGS="-DUSE_SSL -I/usr/local/ssl/include" AUXLIBS="-L/usr/local/ssl/lib -lssl -lcrypto" A później to już tylko make & make install . Jeśli dodatkowo Postfix ma wspierać autoryzacje (SASL), dopisujesz dodatkowe parametry do CCARGS oraz AUXLIBS. Założyłem, że OpenSSL został zainstalowany w domyślnym katalogu (instalacja ze źródeł): /usr/local/ssl/. Pozostały jeszcze dwie rzeczy: konfiguracja w main.cf oraz wygenerowanie kluczy. Omówie to w takiej kolejności, bo mi tak wygodniej. Ty najpierw wygeneruj klucze, dopiero potem zmieniaj konfig (nie musze mówić dlaczego :). Dopisz takie rzeczy do /etc/postfix/main.cf: # włączamy TLS smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes # krótkie info diagnostyczne dla nas smtpd_tls_loglevel = 1 # możemy wymusić TLS przy Autoryzacji ("yes" wymaga SASL) smtpd_tls_auth_only = no # źródło "losowości" tls_random_source = dev:/dev/urandom # klucz smtpd_tls_key_file = /etc/ssl/postfix/key.pem # publiczny certyfikat postfixa smtpd_tls_cert_file = /etc/ssl/postfix/cert.pem # publiczny certyfikat CA smtpd_tls_CAfile = /etc/ssl/postfix/ca.pem Klucze. Czas wygenerować certyfikaty. W naszym konfigu założyliśmy, że trzymamy je w /etc/ssl/postfix/. OpenSSL, ze źródełek instaluje się w /usr/local/ssl. Jeśli masz go gdzieś indziej - znajdź: szukaj pliku CA.sh. Najpierw musisz zostać CA: cd /usr/local/ssl/misc/ ./CA.sh -newca Przyjmij domyślną nazwę pliku, gdy zapyta. Wymyśl i zapamiętaj hasło. Wpisz dane, dowolne, instytucji podpisującej certyfikaty. W ten sposób, w podkatalogu demoCA/ znajdzie się plik cacert.pem. Jeśli nie istnieje katalog /etc/ssl/postfix, utwórz go/je a następnie skopiuj tam ten plik pod nazwą ca.pem (jak w konfigu): cd /usr/local/ssl/misc/demoCA/ cp cacert.pem /etc/ssl/postfix/ca.pem Pozostało wygenerować i podpisać certyfikat dla naszego Postfixa. cd /usr/local/ssl/misc/ ../bin/openssl req -new -nodes -keyout key.pem -out newreq.pem mv key.pem /etc/ssl/postfix/ W momencie gdy pyta o Common Name należy wpisać nazwę serwera poczty. Gdy pyta o adres imejlowy, dobrze jest wpisać adres admina poczty. Gdy pyta o 'extra' parametry - nie wpisujemy nic, walimy w Enter. Pozostało podpisać certyfikat: ./CA.sh -sign mv newcert.pem /etc/ssl/postfix/cert.pem Pyta o hasło - chodzi mu o hasło CA - to, które przed chwilą wymyśliłeś. Gdy w tym momencie się wykrzaczy, sprawdź, czy w zmiennej PATH masz ścieżkę do /usr/local/ssl/bin/. A jak nie, to: export PATH=$PATH:/usr/local/ssl/bin Jeszcze tylko postprzątamy... rm newreq.pem chmod 0600 /etc/ssl/postfix/* Cóż mogę dodać, czas odpalić toto i patrzeć w logi... Jeśli wygląda normalnie - jest dobrze. Teraz telnetuj się na port 25 swojego serwera i zobacz, czy po wpisaniu ehlo [nazwa twojego kompa] /Enter/ zobaczysz STARTTLS. Jeśli tak jest - jest jeszcze lepiej. Pozostało sprawdzić to w praniu... Outlook -> Narzędzia -> Konta -> Właściwości -> Zaawansowane i postaw haczyk przy "Ten serwer wymaga bezpiecznego połączenia (SSL)". Port się nie zmienia, pozostaje 25. Spróbuj coś wysłać, patrz w logi, kliknij OK na ostrzeżenie. Powinno wszystko latać. Od czasu do czasu możesz zobaczyć w logach, jak między serwerami poczty komunikacja przebiega z użyciem TLS (chyba wp.pl ma toto włączone). |
| Posłowie |
Jest to druga wersja dokumentu i zawiera pewnie jakieś błędy/niedoróbki/potknięcia itp. Będę bardzo wdzięczny za wszelkie uwagi, komentarze, poprawki, wyrazy wdzięczności. Z góry przepraszam za powyższe i mam nadzieję, że będziecie mnie informować w których miejscach coś nie gra. Jako (częściowe) wytłumaczenie przedstawiam fakt, że większość tej pracy powstawała w późnych godzinach nocnych. Ostatnia wersja tego dokumentu znajduje się pod niżej wymienionym adresem. Kontakt ze mną: linio@terramail.pl Wesprzyj finansowo autora - kliknij tutaj |
|
=============================== Henryk Liniowski, Poznań 2004 http://linio.terramail.pl =============================== |