Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00152 013973 11052404 na godz. na dobę w sumie
sendmail. Receptury - książka
sendmail. Receptury - książka
Autor: Liczba stron: 416
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-475-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> serwery internetowe >> sendmail
Porównaj ceny (książka, ebook, audiobook).

Zbiór gotowych rozwiązań dla administratorów
serwerów pocztowych

Mimo że sendmail jest najpowszechniej używanym uniksowym serwerem obsługującym pocztę elektroniczną, perspektywa jego konfigurowania wzbudza u administratorów sieci zdecydowanie nieprzyjemne uczucia. Języki wykorzystywane przy konfigurowania sendmaila są bardzo złożone i wykorzystywane stosunkowo rzadko -- podczas instalacji i wstępnej konfiguracji modułu. Z tego właśnie powodu wielu administratorów nie ma zbyt wielu okazji do poznania mechanizmów konfiguracji sendmaila. Kiedy podczas pracy zachodzi nagła potrzeba zmiany konfiguracji tego programu, wszyscy odruchowo sięgają po dokumentację i spędzają wiele godzin na poszukiwaniu w niej rozwiązania swojego problemu.

Książka 'sendmail. Receptury' to zbiór gotowych rozwiązań. Dzięki zawartym w niej poradom administrator szybko i sprawnie rozwiąże niemal każdy problem związany z konfiguracją sendmaila. Nie trzeba już przedzierać się przez setki stron dokumentacji. Koniec z metodą prób i błędów. Każda receptura, poza omówieniem problemu i przedstawieniem gotowego kodu, zawiera także analizę rozwiązania, która jest bardzo pomocna przy dostosowywaniu kodu do własnych potrzeb.

'sendmail. Receptury' to obowiązkowa pozycja dla administratora sieci. Pozwala na zaoszczędzenie nie tylko pracy, ale i czasu.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI sendmail. Receptury KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG Autor: Craig Hunt T³umaczenie: Adam Jarczyk ISBN: 83-7361-475-3 Tytu³ orygina³u: sendmail Cookbook Format: B5, stron: 416 TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Mimo ¿e sendmail jest najpowszechniej u¿ywanym uniksowym serwerem obs³uguj¹cym pocztê elektroniczn¹, perspektywa jego konfigurowania wzbudza u administratorów sieci zdecydowanie nieprzyjemne uczucia. Jêzyki wykorzystywane przy konfigurowania sendmaila s¹ bardzo z³o¿one i wykorzystywane stosunkowo rzadko — podczas instalacji i wstêpnej konfiguracji modu³u. Z tego w³aġnie powodu wielu administratorów nie ma zbyt wielu okazji do poznania mechanizmów konfiguracji sendmaila. Kiedy podczas pracy zachodzi nag³a potrzeba zmiany konfiguracji tego programu, wszyscy odruchowo siêgaj¹ po dokumentacjê i spêdzaj¹ wiele godzin na poszukiwaniu w niej rozwi¹zania swojego problemu. Ksi¹¿ka „sendmail. Receptury” to zbiór gotowych rozwi¹zañ. Dziêki zawartym w niej poradom administrator szybko i sprawnie rozwi¹¿e niemal ka¿dy problem zwi¹zany z konfiguracj¹ sendmaila. Nie trzeba ju¿ przedzieraæ siê przez setki stron dokumentacji. Koniec z metod¹ prób i b³êdów. Ka¿da receptura, poza omówieniem problemu i przedstawieniem gotowego kodu, zawiera tak¿e analizê rozwi¹zania, która jest bardzo pomocna przy dostosowywaniu kodu do w³asnych potrzeb. • Instalacja i wstêpna konfiguracja sendmaila • Dorêczanie i przekazywanie dalej poczty • Tworzenie list wysy³kowych • Maskarada • Kierowanie wiadomoġci • Ochrona kont pocztowych przed spamem • Uwierzytelnianie za pomoc¹ protoko³u AUTH • Korzystanie z protoko³u OpenSSL i obs³uga certyfikatów • Zarz¹dzanie kolejk¹ • Zabezpieczenia sendmaila „sendmail. Receptury” to obowi¹zkowa pozycja dla administratora sieci. Pozwala na zaoszczêdzenie nie tylko pracy, ale i czasu. Spis treści Przedmowa..........................................................................................................................9 Rozdział 1. Początki pracy ...........................................................................................17 1.1. Pobieranie najnowszej wersji...................................................n.................................................21 1.2. Instalacja sendmaila ...................................................n...................................................n. ............28 1.3. Kompilacja sendmaila do korzystania z LDAP...................................................n..................31 1.4. Dodawanie typu mapy regex do sendmaila...................................................n.......................32 1.5. Kompilacja sendmaila z obsługą SASL...................................................n................................34 1.6. Kompilacja sendmaila z obsługą STARTTLS...................................................n......................35 1.7. Wkompilowanie ścieżek do plików STARTTLS ...................................................n................36 1.8. Budowanie konfiguracji sendmaila ...................................................n......................................37 1.9. Testowanie nowej konfiguracji ...................................................n.............................................46 1.10. Rejestrowanie zdarzeń sendmaila ...................................................n........................................50 Rozdział 2. Doręczanie i przekazywanie dalej .........................................................55 2.1. Akceptacja wiadomości przeznaczonych dla innych hostów.............................................58 2.2. Rozwiązanie błędu braku mapy Alias0 i tworzenie prostych aliasów..............................62 2.3. Czytanie aliasów z LDAP ...................................................n......................................................66 2.4. Konfiguracja odczytywania aliasów z serwera NIS w systemie Red Hat ........................71 2.5. Konfiguracja odczytywania aliasów z serwera NIS w systemie Solaris ...........................74 2.6. Przekazywanie dalej pod adres zewnętrzny ...................................................n......................76 2.7. Tworzenie list wysyłkowych...................................................n.................................................77 2.8. Migracja byłych użytkowników pod nowe adresy ...................................................n...........81 2.9. Doręczanie wiadomości do programu...................................................n.................................83 2.10. Używanie nazw programów w listach wysyłkowych ...................................................n......85 6 Spis treści 2.11. Zezwalanie użytkownikom nielogującym się na przekazywanie poczty dalej do programów ...................................................n.................87 2.12. Naprawa pętli .forward...................................................n..........................................................88 2.13. Włączenie bazy użytkowników ...................................................n............................................90 Rozdział 3. Przekaźniki.................................................................................................95 3.1. Przekazywanie całości poczty do przekaźnika ...................................................n..................98 3.2. Przesyłanie poczty wychodzącej do przekaźnika...................................................n............102 3.3. Przekazywanie poczty do węzła pocztowego...................................................n....................103 3.4. Przesyłanie poczty sprawiającej wrażenie lokalnej do przekaźnika................................106 3.5. Przesyłanie poczty UUCP do przekaźnika ...................................................n.......................108 3.6. Przekazywanie poczty dla wszystkich hostów w domenie ..............................................110 3.7. Przekazywanie poczty dla poszczególnych hostów...................................................n........114 3.8. Konfiguracja przekazywania w komputerze wymieniającym pocztę.............................116 3.9. Ładowanie klasy $=R poprzez LDAP...................................................n................................118 3.10. Przekazywanie tylko poczty wychodzącej...................................................n........................121 Rozdział 4. Maskarada................................................................................................125 4.1. Dodawanie domen do wszystkich adresów nadawców...................................................n.127 4.2. Maskarada nazwy hosta nadawcy ...................................................n.....................................129 4.3. Eliminacja maskarady dla lokalnego dostarczyciela poczty .............................................132 4.4. Wymuszanie maskarady dla poczty lokalnej...................................................n.....................135 4.5. Maskarada adresu odbiorcy ...................................................n................................................137 4.6. Maskarada w przekaźniku poczty ...................................................n.....................................139 4.7. Ograniczanie maskarady...................................................n......................................................142 4.8. Maskarada wszystkich hostów w domenie ...................................................n......................145 4.9. Maskarada większości hostów w domenie...................................................n.......................148 4.10. Maskarada adresu koperty ...................................................n..................................................150 4.11. Zmiana adresu From za pomocą genericstable...................................................n................153 4.12. Przekształcanie adresów nadawcy w całej domenie ...................................................n.......158 4.13. Maskarada i LDAP...................................................n...................................................n.... .........161 4.14. Wczytywanie genericstable z LDAP ...................................................n..................................165 Rozdział 5. Kierowanie wiadomości.........................................................................171 5.1. Kierowanie wiadomości do dostarczycieli poczty o specjalnych zastosowaniach........177 5.2. Wysyłanie komunikatów o błędach z mailertable...................................................n...........179 5.3. Wyłączenie przetwarzania MX w celu uniknięcia pętli...................................................n..183 5.4. Kierowanie poczty do doręczenia lokalnego...................................................n....................184 5.5. Czytanie mailertable z LDAP...................................................n..............................................187 Spis treści 7 5.6. Kierowanie poczty przeznaczonej dla poszczególnych hostów wirtualnych ................190 5.7. Kierowanie poczty dla całych domen wirtualnych ...................................................n.........194 5.8. Czytanie virtusertable z LDAP ...................................................n...........................................200 5.9. Kierowanie poczty z użyciem LDAP ...................................................n.................................204 5.10. Kierowanie poczty LDAP w połączeniu z maskaradą...................................................n....213 Rozdział 6. Kontrola nad spamem ............................................................................217 6.1. Blokowanie spamu za pomocą bazy danych access...................................................n........230 6.2. Uniemożliwienie lokalnym użytkownikom odpowiedzi na spam..................................232 6.3. Odczytywanie bazy danych access z LDAP ...................................................n.....................234 6.4. Korzystanie z usługi czarnej listy DNS ...................................................n.............................238 6.5. Tworzenie własnej czarnej listy DNS...................................................n.................................240 6.6. Usuwanie adresów z czarnej listy ...................................................n......................................242 6.7. Filtrowanie lokalnej poczty za pomocą procmaila ...................................................n..........244 6.8. Filtrowanie poczty wychodzącej za pomocą procmaila ...................................................n.246 6.9. Wywoływanie specjalnego przetwarzania nagłówków...................................................n..249 6.10. Używanie w sendmailu wyrażeń regularnych...................................................n.................252 6.11. Identyfikowanie użytkowników lokalnych sprawiających problemy.............................255 6.12. Używanie programów MILTER...................................................n..........................................258 6.13. Omijanie kontroli spamu ...................................................n.....................................................259 6.14. Włączenie kontroli spamu dla poszczególnych użytkowników ......................................261 Rozdział 7. Uwierzytelnianie AUTH ........................................................................263 7.1. Oferowanie uwierzytelniania AUTH...................................................n.................................271 7.2. Uwierzytelnianie przez AUTH ...................................................n...........................................274 7.3. Przechowywanie poświadczeń AUTH w pliku authinfo..................................................279 7.4. Ograniczanie listy ogłaszanych mechanizmów uwierzytelniania ...................................281 7.5. Użycie AUTH do zezwolenia na przekazywanie ...................................................n............283 7.6. Kontrolowanie parametru AUTH= ...................................................n....................................285 7.7. Unikanie podwójnego szyfrowania...................................................n....................................287 7.8. Wymaganie uwierzytelnienia...................................................n..............................................289 7.9. Selektywne żądanie uwierzytelniania ...................................................n...............................293 Rozdział 8. Zabezpieczanie transportu poczty .......................................................297 8.1. Tworzenie prywatnego urzędu certyfikacji ...................................................n......................303 8.2. Tworzenie żądania certyfikatu...................................................n............................................307 8.3. Podpisywanie żądania certyfikatu ...................................................n.....................................309 8.4. Konfiguracja sendmaila dla STARTTLS ...................................................n............................312 8.5. Przekazywanie oparte na CA...................................................n..............................................316 8 Spis treści 8.6. Przekazywanie na podstawie podmiotu certyfikatu...................................................n.......319 8.7. Wymóg szyfrowania połączeń wychodzących ...................................................n................321 8.8. Wymóg szyfrowania połączeń przychodzących...................................................n..............325 8.9. Wymóg zweryfikowanego certyfikatu ...................................................n..............................328 8.10. Żądanie TLS od odbiorcy...................................................n.....................................................331 8.11. Odmowa usługi STARTTLS ...................................................n................................................336 8.12. Selektywne ogłaszanie STARTTLS...................................................n.....................................337 8.13. Żądanie certyfikatu od klienta ...................................................n............................................339 Rozdział 9. Zarządzanie kolejką ...............................................................................341 9.1. Tworzenie kolejek dodatkowych...................................................n........................................344 9.2. Korzystanie z podkatalogów qf, df i xf ...................................................n.............................346 9.3. Definiowanie grup kolejek...................................................n...................................................348 9.4. Przypisywanie odbiorców do konkretnych kolejek ...................................................n........353 9.5. Stosowanie trwałych procedur obsługi kolejki ...................................................n................354 9.6. Wykorzystanie serwera kolejek ...................................................n..........................................357 9.7. Ustawianie liczników czasu protokołu...................................................n..............................359 Rozdział 10. Zabezpieczanie sendmaila ...................................................................363 10.1. Ograniczenie liczby serwerów sendmail...................................................n...........................364 10.2. Ograniczenie liczby serwerów dostępnych z sieci...................................................n...........367 10.3. Aktualizacje zamykające luki w zabezpieczeniach...................................................n..........370 10.4. Poprawki zamykające luki w zabezpieczeniach ...................................................n..............371 10.5. Wyłączenie doręczania do programów ...................................................n.............................374 10.6. Kontrola doręczania do programów...................................................n..................................375 10.7. Wyłączenie doręczania do plików...................................................n......................................379 10.8. Pomijanie pliku .forward użytkownika...................................................n.............................380 10.9. Kontrola nad doręczaniem do plików ...................................................n...............................382 10.10. Uruchomienie sendmaila przez innego użytkownika niż root ........................................383 10.11. Ustawienie bezpiecznego domyślnego ID użytkownika...................................................n387 10.12. Definiowanie zaufanych użytkowników...................................................n...........................389 10.13. Identyfikacja administratora sendmaila ...................................................n............................391 10.14. Ograniczenie zestawu poleceń SMTP ...................................................n................................393 10.15. Żądanie poprawnego HELO ...................................................n...............................................396 10.16. Ograniczenie opcji wiersza polecenia ...................................................n................................397 10.17. Ochrona przed atakami DoS ...................................................n...............................................398 Skorowidz........................................................................................................................401 Kontrola nad spamem 6.0. Wstęp Spam. Można go poznać na pierwszy rzut oka. Każdy spotkał się z tymi absurdalnymi reklamami systemów inwestowania, pornografii, specyfików ziołowych i wszystkiego innego, co tylko możemy sobie wyobrazić. Wielu ekspertów klasyfikuje jako spam wszyst- kie niezamawiane handlowe wiadomości e-mail (UCE — ang. Unsolicited Commercial Email) i istotnie takie wiadomości zaśmiecają skrzynki pocztowe na całej kuli ziemskiej. Jednakże legalni ogłoszeniodawcy, którzy oferują realne opcje wycofywania reklam, nie stanowią najgorszego problemu.1 Prawdziwym problemem są spamerzy. Od prawowitych ogłosze- niodawców różni ich to, że spamerzy ukrywają swoją tożsamość i nadużywają cudzych systemów pocztowych. Można ich poznać po tym, że: • Ukrywają źródło swoich wiadomości e-mail, aby nikt nie winedział, kto je wysyła. Pełnoprawni ogłoszeniodawcy z dumą wyświetlają nazwę swnojej firmy w adresie nadawcy. Każdy ogłoszeniodawca, który tego nie robi, ma przypuszczalnie powody, by ukrywać swoją tożsamość i swoje działania, i powinien być uważany za spamera. Nadużywają usług w cudzych systemach, wykorzystując je jako nnieautoryzowane • przekaźniki. Wysyłają informacje, których nigdy nie zamawialiśmy. Na lnistę wysyłkową • spamera nie zapisujemy się osobiście, a gdy wiadomość od spamera zawiera opcję rezygnacji z przysyłania reklam, jej użycie nie powodunje usunięcia użytkownika z żadnej listy wysyłkowej. Zamiast tego opcja służy do gromadzenia adresów e-mail sprzedawanych następnie innym spamerom Każdy z nas powinien pomagać w walce ze spamem, gwarantując, że nasz system pocz- towy nie będzie nadużywany przez spamerów z zewnątrz, i że lokalni użytkownicy nie będą wysyłać niechcianych wiadomości. 1 Puryści pomstują na opcje rezygnacji z reklam, lecz takie metody mogą być skuteczne, jeśli na- prawdę są implementowane. 218 Rozdział 6. Kontrola nad spamem Spamerzy do ukrywania swojej tożsamości używają otwartych przekaźników poczty (ang. open relay). Receptury przedstawione w rozdziale 3. pokazują, jak można skonfigurować przekaźnik poczty. Po każdej zmianie konfiguracji powinniśmy przetestować przekaźnik tak jak w rozdziale 3., aby uniknąć nadużycia systemu.n Pierwszym krokiem w walce z lokalnymi spamerami jest stworzenie zasad dopuszczal- nego użytkowania, które będą zakazywać rozsyłania spamu i zdefiniują działania, jakie podejmiemy w celu powstrzymania emisji spamu. Zasady powinny jasno informować, że poczta e-mail nie jest prywatna i może podlegać rejestrowaniu, skanowaniu i filtrowaniu. Ponieważ takie zasady są oficjalne, muszą zostać zaaprobowane i wydane przez kierow- nictwo oraz przejrzane i zaaprobowane przez biuro prawne. Zasady zawsze sprawiają kłopoty, ponieważ nie są rozwiązaniami technicznymi i wymagają udziału kierownictwa. Jednakże ten krok jest niezbędny, ponieważ daje nam uprawnienia do analizy poczty. Po wprowadzeniu zasad wszyscy użytkownicy muszą wyrazić na nie zgodę, aby otrzymać konto użytkownika. Oprócz zapewnienia, że nasz system nie będzie czynnie przyczyniał się do produkcji spa- mu, istnieją narzędzia techniczne, które mogą posłużyć do aktywnego zwalczania spamu. sendmail zawiera szereg narzędzi do walki z niechciannymi reklamami: Baza danych access blokuje pocztę z i do określonych systemów. • Listy „czarnych dziur” (ang. blackhole lists) DNS blokują wiadomości • od przypuszczalnych spamerów i z otwartych przekaźnikówn poczty. Programy filtrujące pocztę, np. procmail, są dostępne z nsendmaila i potrafią • filtrować pocztę na podstawie treści wiadomości Przetwarzanie nagłówka w sendmailu może wykrywać ninekonsekwentne i źle • zbudowane nagłówki. sendmail automatycznie przeprowadza testy poprawnościn logicznej, na przykład • sprawdza, czy domena nadawcy może być rozwiązana przenz DNS. Baza danych access Baza danych access pozwala na precyzyjną kontrolę nad przekazywaniem i doręczaniem poczty. Użycie funkcji access_db dodaje bazę danych access do konfiguracji sendmaila: FEATURE(`access_db ) Domyślnie baza danych access jest typu hash i mieści się w pliku /etc/mail/access.db. Za pomocą opcjonalnego pola argumentu w funkcji access_db możemy zmienić te domyślne ustawienia, jak w przykładzie: FEATURE(`access_db , `btree -T TMPF /var/mail/accecss ) Ten wpis zmienia typ bazy danych, dodaje opcję -T TMPF związaną z obsługą tymcza- sowych problemów z wyszukiwaniem i zmienia ścieżkę do pliku bazy danych. Ustawienia domyślne powinniśmy zmieniać tylko w razie absolutnenj konieczności. 6.0. Wstęp 219 Każdy wiersz w bazie danych access zawiera dwa pola: klucz i wartość zwracaną. Gdy używamy tej bazy danych do kontroli nad spamem, kluczem jest adres, a wartością zwra- caną akcja, którą sendmail powinien podjąć w związku z wiadomością przychodzącą lub wychodzącą spod podanego adresu. Gdy używaliśmy bazy danych access w rozdziale 3., wartością zwracaną było, jak łatwo się domyślić, słowo kluczowe RELAY. Receptury znaj- dujące się w niniejszym rozdziale wykorzystują bazę danych do ustalenia, czy wiadomość powinna być zaakceptowana lub doręczona pod podany adres. Do tego celu potrzebny będzie zestaw innych wartości zwracanych. Słowa kluczowe stosujące się do kontroli spamu zostały wymienione w tabeli 6.1. Tabela 6.1. Słowa kluczowe bazy danych access służąSce do kontroli nad spamem Słowo kluczowe Czynność OK DISCARD REJECT Akceptuje wiadomości do i spod podanego adresu. Odrzuca wszystkie wiadomości do i spod podanego adroesu. Zwraca komunikat o błędzie i odrzuca wszystkie wiadoomości do i spod podanego adresu. ERROR:dsn:kod tekst Odrzuca wiadomość z podanym kodem odpowiedzi i komuonikatem o błędzie. HATER FRIEND Dodaje zestawy reguł check_mail i check_relay dla wiadomości do podanego odbiorcy. Pomija zestawy reguł check_mail i check_relay dla wiadomości do podanego odbiorcy. Polecenie OK powoduje zaakceptowanie przez sendmail wiadomości ze źródła określone- go przez pole klucza, niezależnie od innych warunków. Na przykład, jeśli nazwy hosta podanej w adresie nie można rozwiązać w DNS-ie, sendmail będzie akceptował wiado- mość, nawet jeśli funkcja accept_unresolvable_domains nie będzie włączona. OK akceptuje wiadomości przeznaczone do doręczenia lokalnie, lecz nie nadaje przywileju przekazy- wania. Do tego celu byłoby wymagane słowo kluczowe RELAY, opisane w rozdziale 3. Słowo kluczowe REJECT zwraca standardowy komunikat błędu do źródła i odrzuca wiado- mość. Akcja DISCARD odrzuca wiadomość bez odsyłania komunikatu o błędzie do nadaw- cy. Wiele organizacji zajmujących się zwalczaniem spamu nie zgadza się z ideą odrzu- cania wiadomości „po cichu”, ponieważ ich zdaniem nie zniechęca to spamerów. Z punktu widzenia spamera wiadomość sprawia wrażenie odebranej, więc dalej będzie nadawał swoje śmieci. Inne organizacje preferują odrzucanie wiadomości bez odpowiedzi, ponie- waż uważają, że odpowiedź na wiadomość w dowolnej postaci jest dla spamera weryfi- kacją adresu i zachęca go do dalszych ataków. Oba podejścia chronią użytkowników przed spamerem, jednakże użycie akcji REJECT, która zwraca komunikat o błędzie do źródła wiadomości, pomaga w tych przypadkach, gdy pełnoprawna wiadomość zostanie błędnie sklasyfikowana jako spam, ponieważ informuje nadawcę,n że wiadomość została odrzucona. Akcja REJECT wysyła domyślny komunikat błędu. Możemy użyć słowa kluczowego ERROR, aby odrzucić wiadomość, odsyłając własny komunikat o bnłędzie: example.com ERROR:5.7.1:550 Nie przekazujemy spamu 220 Rozdział 6. Kontrola nad spamem W tym przypadku komunikat o błędzie zwracany do nadawcy będzie brzmiał „Nie prze- kazujemy spamu”. Komunikat zawiera kod powiadomienia o stanie doręczenia 5.7.1 i kod błędu SMTP 550. Powinniśmy zastosować poprawny kod DSN z dokumentu RFC 1893, zgodny z kodem błędu z RFC 821 i komunikatem tekstowym.2 Format komu- nikatu błędu przedstawiony w tabeli 6.1 to ERROR:dsn:kod tekst. Taki format jest zale- cany, lecz nie jest wymagany. Możemy pominąć słowo kluczowe ERROR lub kod DSN, jednakże taki starszy format błędu jest odradzany. Aby zapewnić zgodność z przyszłymi wersjami sendmaila, powinniśmy używać słowa kluczowego ERROR i kodu DSN. Słowa kluczowe FRIEND i HATER stosują się tylko wtedy, gdy funkcja delay_checks jest włą- czona do kontrolowania, kiedy mają być zastosowane zestawy reguł check_mail i check_ relay. Słowo kluczowe FRIEND w wartości zwracanej pozwala wiadomościom, które nor- malnie zostałyby odrzucone przez check_mail lub check_relay, przejść przez system do odbiorcy podanego w polu klucza. Gdy używane jest słowo kluczowe HATER, check_mail i check_relay są stosowane tylko względem odbiorców, dla których to słowo figuruje we wpisie do bazy danych. FRIEND i HATER nie mogą jednocześnie pojawić się w tej samej bazie danych access, ponieważ funkcja delay_checks musi zostać skonfigurowana do przyj- mowania albo słowa kluczowego FRIEND, albo HATER — nie może akceptować jednocze- śnie obu. Receptura 6.13 przedstawia przykład użycia tychn słów kluczowych. Większość akcji pokazanych w tabeli 6.1 została opisana jako wpływające na wiadomości „do lub spod” adresu. Jest to prawdą tylko wtedy, gdy używane są znaczniki lub funkcja blacklist_recipients. Gdy funkcja ta nie jest używana, opisane akcje wpływają jedynie na wiadomości pochodzące z adresu źródłowego, chyba że pole adresu jest zmodyfikowane przez opcjonalny znacznik To:, From: lub Connect:. Znaczniki te ograniczają test adresu odpowiednio do odbiorcy koperty, do nadawcy koperty i do adresu połączenia. Na przy- kład wpis w bazie danych access odrzucający połączenia z 10.0.187.215 może zawierać: Connect:10.0.187.215 ERROR:5.7.1:550 Nie przyjmujemy spamu Znacznik Connect: ogranicza dopasowanie do adresu zdalnego systemu, który połączył się z serwerem w celu doręczenia poczty. Jeśli adresem tym będzie 10.0.187.215, wiadomość zostanie odrzucona i do nadawcy zostanie zwrócony komunikat „Nie przyjmujemy UCE”. Adres w polu klucza wpisu w bazie danych access może definiować użytkownika, poje- dynczy adres e-mail, źródłowy adres IP, adres sieciowy nlub nazwę domeny: Osoba jest definiowana z użyciem albo pełnego adresu ne-mail w postaci • użytkownik@host.domena, albo nazwy użytkownika w postaci nazwaużytkownika@. Host jest identyfikowany przez nazwę lub adres IP. • Domena jest identyfikowana przez nazwę domeny. • Sieć jest identyfikowana przez składnik sieci w adrensie IP. • 2 Rozdział 5. zawiera dodatkowe informacje o kodach DSN i słowach kluczowych kodów SMTP. Patrz też RFC 2821. 6.0. Wstęp 221 Oprócz powyższego przykładu Connect: w bazie danych access do identyfikacji poczty z 10.0.187.215 mogą zostać użyte inne formaty. Oto kilka z nnich: 10.0.187 REJECT [10.0.187.215] DISCARD example.com ERROR:5.7.1:550 Wiadomość odrzucona. Dwa pierwsze wiersze w tej bazie danych access dopasowują adresy IP. Pierwszy wpis odrzuca wiadomości z każdego komputera, którego adres IP zaczyna się od numeru sieci 10.0.187, z której pochodziły niepożądane reklamy. Drugi wiersz definiuje konkretny kom- puter o adresie 10.0.187.215. Nawiasy prostokątne obejmujące pojedynczy adres oznaczają, że ten adres IP nie rozwiązuje się na nazwę hosta. Ostatni wpis definiuje całą domenę, powodując odrzucenie poczty z każdego hosta w do- menie example.com. Oczywiście nie użylibyśmy tej metody, gdybyśmy otrzymali tylko jedną wiadomość z reklamą z tej domeny, lecz gdyby nasz system regularnie odbierał z niej spam, moglibyśmy zablokować wszelką pocztę pochodzącą z tej domeny, dopóki jej administrato- rzy nie poprawiliby bezpieczeństwa. Funkcja dnsbl udostępnia kolejną metodę blokowania poczty z określonych hostów i domen. Czarne listy dla dnsbl i enhdnsbl Dodanie funkcji dnsbl do konfiguracji sendmaila pozwala użyć list źródeł spamu, tzw. czarnych list do blokowania spamu. Są to bazy danych DNS identyfikujące źródła przy- czyniające się do rozsyłania spamu. Źródłem takim może być zarówno oryginalny nadaw- ca spamu, jak i otwarty przekaźnik poczty pozwalający spamerom rozsyłać wiadomości. Usługi czarnych list są implementowane poprzez DNS. Każdy system uniksowy może wysyłać zapytania DNS, więc jest to bardzo skuteczny sposób dystrybucji informacji. Oczywiście program może wykorzystać informacje tylko wtedy, gdy je rozumie tak jak sendmail. Funkcja dnsbl przyjmuje dwa opcjonalne argumenty. Pierwszym jest nazwa domeny zawie- rającej listę. Domyślnym ustawieniem jest Realtime Blackhole List (RBL) utrzymywana przez Mail Abuse Prevention System (MAPS). Kilka innych grup również utrzymuje i udostępnia publicznie takie listy. Tabela 6.2 zawiera kilka z nicnh. Tabela 6.2. Usługi czarnych list Nazwa usługi Strona WWW Nazwa domeny Spamhaus Block List www.spamhaus.org sbl.spamhaus.org Relay Stop List relays.visi.com relays.visi.com Distributed Server Boycott List dsbl.org list.dsbl.org MAPS RBL mail-abuse.org Niepotrzebna. To jest domyślne ustawienie dnsbl. Aby użyć czarnej listy z tabeli 6.2, należy w pierwszynm argumencie dnsbl wskazać domenę podaną w tabeli. Na przykład następujące polecenie skonfiguruje użycie przez sendmail Spamhaus Block List: 222 Rozdział 6. Kontrola nad spamem FEATURE(`dnsbl , `sbl.spamhaus.org ) Zasady wymuszane przez różne czarne listy mogą być odmienne. Większość z tych usług koncentruje się na blokowaniu otwartych przekaźników, a nie na źródłach spamu. Powo- dem tego jest fakt, że źródła spamu nieustannie się zmieniają i ukrywają swoje prawdziwe tożsamości. Pomagają im w tym, chociaż niechcący, otwarte przekaźniki. Otwarty prze- kaźnik poczty zwykle nie chce pomagać spamerom. Zablokowanie poczty z otwartego przekaźnika szybko przyciąga uwagę jego administratora, który poprawia ustawienia systemu i przez to blokuje spamerowi dostęp do zasobów. Taka pośrednia metoda obrony przed spamem sprawia problemy wielu niewinnym, chociaż naiwnym, użytkownikom sieci. Z tego powodu czarne listy są często uważane za lekarstwo równie szkodliwe jak sama choroba, i wiele osób odradza korzystanie z taknich list. Na publicznych czarnych listach znajduje się wiele systemów. Każdy ośrodek, który prze- kazuje spam — może być nim nawet nasz system, jeśli nie skonfigurujemy poprawnie sendmaila — ma dużą szansę znaleźć się na czarnej liście. Z tego powodu ważna jest po- prawna konfiguracja przekazywania. Pomyłka w konfiguracji przekaźnika może spowo- dować, że nasz serwer wyląduje na czarnej liście. Gdy ośrodek kończy z przekazywaniem spamu, powinien zostać usunięty z listy po okresie około miesiąca. Oczywiście te zasady są różne dla różnych list, podobnie jak skuteczność, z jaką adresy są dodawane i usuwa- ne z listy. Jeśli nasz adres zostanie dodany na czarną listę, powinniśmy rozwiązać pro- blem i zgłosić adres do usunięcia z listy, postępując zgodnie z instrukcjami dostępnymi w serwisie WWW listy. Zanim zaczniemy korzystać z usług czarnych list, powinniśmy odwiedzić serwisy WWW każdej z nich i dowiedzieć się czengoś więcej o liście. Najprostszym sposobem blokowania spamu jest pozostawienie tego komuś innemu. Z dru- giej strony, chociaż korzystanie z publicznych czarnych list jest proste, to rozwiązanie nie jest doskonałe. Nie możemy wybierać adresów dodawanych do listy, co oznacza, że lista może blokować pocztę z „uczciwego” serwera tylko dlatego, że jego administrator zapo- mniał wyłączyć przekazywanie. Możemy jednak ignorować poszczególne wpisy z czarnej listy za pomocą bazy danych access (patrz receptura 6.4). Aby osiągnąć jeszcze dokład- niejszą kontrolę, niektóre organizacje tworzą własne czarne listy oparte na usłudze DNS. Receptura 6.5 pokazuje, jak możemy zbudować i wykorzystnać własną czarną listę. Drugim argumentem dostępnym w funkcji dnsbl jest komunikat o błędzie wyświetlany, gdy wiadomość zostaje odrzucona na podstawie informacji z serwera czarnej listy. Format domyślnego komunikatu wygląda następująco: 550 Rejected $ {client_addr} listed at dnsbl-domain gdzie {client_addr} jest adresem IP, który został odrzucony, a domena-dnsbl oznacza czarną listę DNS, która odrzuciła adres (tzn. domena-dnsbl jest wartością z pierwszego argumentu podanego dla funkcji dnsbl). Drugiego argumentu dnsbl możemy użyć tylko wtedy, gdy chcemy zmienić standardowy komunikat błędu. Większość administratorów pozostaje przy pierwszym komunikacie. Trzeci argument dostępny dla funkcji dnsbl pozwala określić, jak będą traktowane przej- ściowe błędy w wyszukiwaniu DNS. Domyślnie sendmail nie wstrzymuje wiadomości tylko dlatego, że usługa czarnej listy nie potrafi odpowiedzieć na wyszukiwanie przez 6.0. Wstęp 223 DNS. Umieszczenie t w polu trzeciego argumentu spowoduje, że sendmail będzie zwra- cał komunikat o przejściowym problemie i wstrzyma wiadnomości. Oto przykład: FEATURE(`dnsbl , `sbl.spamhaus.org , ,`t ) Alternatywą dla funkcji dnsbl jest funkcja enhdnsbl. Składnia funkcji enhdnsbl ma trzy pierw- sze argumenty takie same jak dnsbl, lecz dodaje czwarty argument, którym jest wartość zwracana, jakiej sendmail spodziewa się z wyszukiwania przez DNS. Domyślnie dowol- na wartość zwracana przez wyszukiwanie przez DNS w usłudze czarnej listy wskazuje, że sprawdzany adres znajduje się na liście usługi i powinien zostać odrzucony. Czwarty argument pozwala zmienić to zachowanie tak, że tylko wartość pasująca do niego będzie powodowała odrzucenie wiadomości. Argumentem tym nie musi być pojedyncza wartość: może to być lista wartości lub takie same operatory jak po lewej stronie reguły przekształ- ceń, pasujące do wielu wartości. Oto przykład funkcji enhdnsbl: FEATURE(`enhdnsbl , `sbl.spamhaus.org , , ,`127.0.0.2 , `127.0.0.3. ) Ten wpis makra włącza funkcję enhdnsbl i używa usługi czarnej listy sbl.spamhaus.org. Zgod- nie z nim sendmail będzie odrzucał przychodzące wiadomości, gdy usługa czarnej listy w odpowiedzi na wyszukiwanie adresu połączenia zwrócin wartość 127.0.0.2 lub 127.0.0.3. Baza danych access i czarne listy blokują pocztę ze znanych źródeł spamu i z otwartych przekaźników. Lecz nie wszystkie niechciane reklamy pochodzą ze znanych źródeł spamu. Czasem dopiero po przeczytaniu zorientujemy się, że mamy do czynienia z taką pocztą. Narzędzia filtrujące pocztę mogą sprawdzać zawartość wiadomości i na jej podstawie decydować, jak wiadomość ma zostać potraktowana. MILTER sendmail udostępnia poprzez interfejs gniazd bezpośredni dostęp do zewnętrznych pro- gramów filtrujących pocztę, zwanych MILTER i napisanych zgodnie z Sendmail Mail Filter API. Zewnętrzne filtry poczty są definiowane w konfiguracji sendmaila za pomocą makr INPUT_MAIL_FILTER lub MAIL_FILTER. Poza nazwą składnia obu makr jest identyczna. Na przykład składnia makra INPUT_MAIL_FILTER wygląda następująco: INPUT_MAIL_FILTER(nazwa, przyrównania) nazwa jest arbitralną nazwą używaną przez sendmail, podobnie jak wewnętrzne nazwy dostarczycieli poczty i baz danych. W składni znajdują się maksymalnie trzy przyrów- nania zapisane w postaci litera=wartość, gdzie literą może być: S Przyrównanie S jest wymagane, ponieważ definiuje gniazdo służące do komunikacji z zewnętrznym filtrem. Definicja gniazda jest zapisana w formie S=typ:specyfikacja, gdzie typ oznacza typ gniazda, a specyfikacja definiuje gniazdo w sposób wymagany dla danego typu gniazda. Obsługiwane są trzy typy gnniazd: S=unix:ścieżka Gniazda uniksowe są obsługiwane; ścieżka oznacza pełną ścieżkę do takiego gniaz- da. Słowo kluczowe unix może być zastąpione synonimem local (np. S=local:/ var/run/filter1.sock). 224 Rozdział 6. Kontrola nad spamem S=inet:port@host Słowo kluczowe inet żąda gniazda IP. port oznacza numer portu sieciowego uży- wanego przez filtr. host jest nazwą hosta lub adresem IP systemu, w którym filtr jest uruchomiony. S=inet6:port@host Gniazda IPv6 również są obsługiwane. Słowo kluczowe inet6 żąda gniazda IPv6, port identyfikuje numer portu sieciowego używanego przez filtr, a host system, w którym filtr jest uruchomiony. Jako wartość host może zostać zapisany adres IPv6 lub nazwa hosta odwzorowująca się na adres IPv6. F=litera To opcjonalne przyrównanie pozwala zdefiniować sposób reakcji na błąd gniazda. Domyślnie w razie awarii gniazda lub nieoczekiwanej odpowiedzi filtru sendmail kon- tynuuje przetwarzanie wiadomości. Przyrównanie F=R pozwala w przypadku pro- blemów z gniazdem lub filtrem odrzucić połączenie z trwałym błędem, a F=T z błę- dem tymczasowym. T=litera:wartość;litera:wartość;... Użycie tego opcjonalnego przyrównania pozwala zmienić domyślne czasy oczekiwania. Dostępne są cztery wartości literowe: C E R S Definiuje czas oczekiwania na połączenie. Domyślnie czas oczekiwania upływa, gdy nie można nawiązać połączenia przez 5 minut (5m). Definiuje ogólny czas oczekiwania, domyślnie 5 minut (5m). Definiuje czas oczekiwania na odczyt odpowiedzi z filtnru, domyślnie 10 sekund (10s). Definiuje czas oczekiwania przy wysyłaniu danych do filtru, domyślnie 10 sekund (10s). Przy takiej składni makro INPUT_MAIL_FILTER dodające obsługę zewnętrznego programu MIMEDefang może wyglądać następująco: INPUT_MAIL_FILTER(`mimedefang ,`S=unix:/var/run/mimedefang.sock, T=S:5mc;R:5m ) Powyższe makro definiuje dla tego filtru wewnętrzną nazwę mimedefang. sendmail utwo- rzy gniazdo /var/run/mimedefang.sock i będzie komunikować się z filtrem przez to gniaz- do uniksowe. Ponieważ sendmail tworzy gniazdo, nie powinno ono uprzednio istnieć. W powyższym przykładzie nie zostało użyte przyrównanie F, więc sendmail będzie stan- dardowo przetwarzać wiadomości nawet w przypadku błędu gniazda lub nieprawidło- wej odpowiedzi filtru. Przyrównanie T zwiększa liczniki czasu dla wysyłania i odbioru do pięciu minut. 6.0. Wstęp 225 Makro INPUT_MAIL_FILTER definiuje tylko jeden filtr. Aby użyć większej liczby filtrów, możemy dodać do konfiguracji sendmaila większą liczbę makr INPUT_MAIL_FILTER lub MAIL_FILTER. Gdy używamy wielu filtrów, różnica między INPUT_MAIL_FILTER i MAIL_ FILTER staje się widoczna. Załóżmy na przykład, że konfiguracja sendmaila zawiera na- stępujące makra: INPUT_MAIL_FILTER(`filtr1 , `S=unix:/var/run/filtr1.soc ) INPUT_MAIL_FILTER(`filtr2 , `S=unix:/var/run/filtr2.soc ) INPUT_MAIL_FILTER(`filtr3 , `S=unix:/var/run/filtr3.soc ) Makro INPUT_MAIL_FILTER określa kolejność, w której filtry będą używane. Biorąc pod uwagę trzy powyższe makra i kolejność ich zapisania, sendmail będzie przesyłać dane przez filtr1, filtr2 i filtr3 w tej właśnie kolejności. Aby utworzyć równoważną kon- figurację za pomocą makr MAIL_FILTER, potrzebne będą cztery wiersze w konfiguracji sendmaila: MAIL_FILTER(`filtr1 , `S=unix:/var/run/filtr1.soc ) MAIL_FILTER(`filtr2 , `S=unix:/var/run/filtr2.soc ) MAIL_FILTER(`filtr3 , `S=unix:/var/run/filtr3.soc ) define(`confINPUT_MAIL_FILTERS , `filtr1, filtr2, filtr3 ) Makra MAIL_FILTER nie ustalają kolejności użycia filtrów, więc musi im towarzyszyć defi- nicja confINPUT_MAIL_FILTERS określająca kolejność wykonania. Gdyby definicja conf åINPUT_MAIL_FILTERS nie została użyta razem z makrami MAIL_FILTER, filtry zdefinio- wane przez te makra byłyby ignorowane. Oczywiście przy użyciu makr MAIL_FILTER i definicji confINPUT_MAIL_FILTERS filtry pocztowe nie muszą być stosowane w kolej- ności ich deklarowania. Na przykład, zmieniając definicję confINPUT_MAIL_FILTERS na poniższą, uruchomimy filtry w odwrotnej kolejności: define(`confINPUT_MAIL_FILTERS , `filtr3, filtr2, filtr1 ) Filtry używane przez sendmail są programami zewnętrznymi. Każdy w miarę doświad- czony programista może napisać prosty program filtrujący pocztę, lecz stworzenie filtru, który naprawdę skutecznie będzie zwalczał nadużycia poczty, stanowi poważne wyzwa- nie. Na szczęście wielu dobrych programistów napisało już przydatne filtry. Aby nie wy- ważać otwartych drzwi, najlepiej będzie, jeśli najpierw poszukamy w internecie filtrów, które mogą rozwiązać nasze problemy z pocztą. Oto kilka miejsc, od których możemy zacząć poszukiwania: http://www.milter.org/ Ogólne źródło informacji o programach MILTER. http://www.mimedefang.org/ Potężny i rozszerzalny MILTER obsługujący skanowanie w poszukiwaniu wirusów, usuwanie załączników na podstawie nazwy i zawartości oraz przetwarzanie Spam åAssassin3. 3 Informacje o programie SpamAssassin znajdziemy pod adoresem http://spamassassin.org/. 226 Rozdział 6. Kontrola nad spamem http://www.snert.com/Software/milter-sender/ MILTER próbujący weryfikować, czy adres nadawcy jest prawdziwy. Wielu spamerów nie używa prawdziwych adresów nadawcy. http://www.amavis.org/ MILTER skanujący w poszukiwaniu wirusów. http://sendmail.com/ Sendmail, Inc. udostępnia szereg komercyjnych programówn MILTER. Istnieje wiele innych witryn WWW związanych z programami MILTER i wiele innych takich programów. Jednakże nie są one jedynymi narzędziami dostępnymi do filtrowania poczty — powszechnie stosowany jest również procmail. Filtrowanie za pomocą programu procmail Większość tekstów dotyczących sendmaila (a niniejszy nie jest wyjątkiem) w filtrowaniu poczty koncentruje się na programie procmail. Istnieje nku temu kilka powodów: procmail jest ściśle zintegrowany z sendmailem. • procmail jest potężnym narzędziem, które może posłużyć do wnielu innych • zastosowań poza filtrowaniem spamu. procmail jest domyślnym programem doręczającym lokalne wiadomościn w systemie • Linux i może być używany jako dostarczyciel poczty local w każdym systemie uniksowym, jeśli dodamy do konfiguracji sendmaila funkncję local_procmail. Polecenie MAILER(procmail) dodaje procmail do listy dostarczycieli poczty sendmaila. • Różnorodność sposobów wywoływania programu procmail zwiększa elastyczność tego narzędzia. Jak wspomniano powyżej, możemy skonfigurować sendmail do korzystania z procmaila w roli dostarczyciela poczty local. procmail może być też uruchomiony z poziomu wiersza poleceń powłoki, z mailertable, jak w recepturze 6.8, oraz z pliku .forward użytkownika, jak poniżej: $ cat .forward |/usr/bin/procmail Ctrl-D Powszechnie spotykanym błędem jest myślenie, że jeśli filtry poczty o zasięgu całego systemu wpływają na dużą liczbę użytkowników, to najważniejsze filtrowanie wiadomo- ści odbywa się na poziomie systemu. Filtrowanie poczty na poziomie użytkownika jest równie ważne. Filtry użytkownika: Stanowią ostatnią linię obrony przed spamem, który pnrzedostaje się przez filtry • systemu. Pozwalają użytkownikom egzekwować własne zasady pocztyn elektronicznej. • 6.0. Wstęp 227 Pozwalają na filtrowanie na podstawie zawartości bez onbawy o naruszenie • prywatności. Mają do przetworzenia znacznie mniejsze objętości poczty.n • Z tych i innych powodów warto zachęcać użytkowników do poznania i korzystania z dostępnych dla nich filtrów poczty. Wiele narzędzi pocztowych przeznaczonych dla użytkowników końcowych zawiera funkcje filtrowania poczty. Nie są one zintegrowane z sendmailem, więc nie będą tu omawiane. procmail jest potężnym, aczkolwiek złożonym systemem filtrowania poczty. Osobiste fil- try procmaila są definiowane przez użytkownika w jego katalogu macierzystym w pliku o nazwie .procmailrc. Administrator systemu definiuje filtry poczty obowiązujące dla całego systemu w pliku /etc/procmailrc i wykorzystuje ten plik do ogólnego filtrowania spamu. Użytkownik końcowy za pomocą pliku .procmailrc dodaje własne filtrowanie zgodnie ze swoimi preferencjami. Format obu plików jest taki sam.n Plik .procmailrc zawiera dwa typy wpisów — przypisania zmiennych środowiskowych i reguły filtrowania poczty, które w żargonie procmaila noszą nazwę regułek (dosłownie receptur — recipe). Przypisania zmiennych środowiskowych są oczywiste i wyglądają tak samo jak w skryptach powłoki. Na przykład HOME=/home/craig jest poprawnym przy- pisaniem zmiennej środowiskowej. Dokumentacja man pliku .procmailrc wymienia ponad 30 zmiennych środowiskowych. Główną treścią pliku .procmailrc są regułki. Składnia każdej regułki wygląda następująnco: :0 [znaczniki] [:[lockfile]] [* warunek] akcja Każda regułka zaczyna się od :0, co odróżnia ją od instrukcji przypisania. Po :0 opcjo- nalnie następują znaczniki zmieniające przetwarzanie przez filtr. Tabela 6.3 wymienia znaczniki i ich zastosowania. Opcjonalna zmienna lockfile pozwala podać nazwę lokalnego pliku blokady, który będzie użyty dla tej regułki. Plik blokady zapobiega jednoczesnemu zapisywaniu do tej samej skrzynki pocztowej przez większą liczbę kopii programu procmail, co może zdarzyć się w intensywnie używanym systemie. Nazwę pliku blokady poprzedza dwukropek. Jeśli użyjemy dwukropka bez podania nazwy pliku, zostanie użyta domyślna nazwa lockfile utworzona z nazwy skrzynki pocztowej z rozszerzeniem .lock. Jeśli nie podamy żadnego lokalnego pliku blokady, zostanie użyty plik domyślny, jednakże dokumentacja procmaila zaleca korzystanie z lokalnych plików blokady. Test warunku jest opcjonalny. Jeśli warunek nie zostanie podany, regułka zadziała tak, jakby warunek był prawdziwy, co oznacza podjęcie działania. Jeśli podajemy warunek, musimy zacząć go od znaku gwiazdki (*). warunek jest zapisywany w postaci wyrażenia regularnego. Jeśli wartość zdefiniowana przez wyrażenie regularne zostanie znaleziona w wiadomości, warunek zostaje rozwiązany jako prawda i akcja zostaje podjęta. Aby podjąć akcję, gdy wiadomość nie zawiera podanej wartości, wyrażenie regularne musi zaczynać się od wykrzyknika. Oto dwa przykłady poprawnych testnów warunku: 228 Rozdział 6. Kontrola nad spamem Tabela 6.3. Znaczniki regułek procmaila Znacznik Znaczenie A a b B c D e E f H h I r w W Wykonaj tę regułkę, jeśli poprzednia zwróciła wartość oprawda. To samo znaczenie co znacznik A, lecz dodatkowo poprzedzająca regułka musi zostać z powodzeniem wykonana. Przekaż treść wiadomości do miejsca przeznaczenia. oOpcja domyślna. Filtruj treść wiadomości. Utwórz kopię DW tej wiadomości. Testy rozróżniają wielkość liter. Domyślnie wielkość loiter jest ignorowana. Wykonaj tę regułkę, jeśli wykonanie poprzedniej receoptury zwróciło błąd. Wykonaj tę regułkę, jeśli poprzednia nie była wykonanoa. Prześlij dane przez zewnętrzny program filtrujący. Filtruj nagłówki wiadomości. Opcja domyślna. Przekaż nagłówek wiadomości do miejsca przeznaczenia.o Opcja domyślna. Ignoruj błędy zapisu w tej regułce. Zapisz wiadomość bez dodatkowego sprawdzania formatuo. Sprawdź kod zakończenia zewnętrznego programu filtrujoącego. To samo co znacznik w, lecz komunikat o błędzie nie jest wysyłany na wyjśocie. * ^From.*simon@oreilly.com * !^Subject: Chapter Pierwszy warunek sprawdza, czy wiadomość zawiera wiersz zaczynający się (^) od ciągu znaków From, po którym następuje dowolna liczba znaków (.*) i ciąg simon@oreilly.com. Drugi warunek pasuje do wszystkich wiadomości niezawierających (!) wiersza zaczynają- cego się od łańcucha Subject: Chapter. Jeśli w jednej regułce zdefiniowana jest większa liczba warunków, każdy warunek powinien znaleźć się w osobnym wierszu. Wprawdzie regułka procmaila może zawierać wiele warunków, lecz tylko jedną akcję. Akcja może przekierować wiadomość do pliku, przekazać dalej pod inny adres e-mail, wysłać do programu lub zdefiniować dodatkowe regułki, które będą przetwarzać wiadomość. Jeśli akcja jest regułką dodatkową, to zaczyna się od :0. Jeśli kieruje pod adres e-mail, powinna zacząć się od wykrzyknika (!), a jeśli kieruje do programu, zaczyna się od sym- bolu pionowej poprzeczki (|). Jeśli akcja wysyła wiadomość do pliku, podawana jest tylko nazwa tego pliku. Poniższy przykład ilustruje, jak poczta jest przekazywana do przetwo- rzenia przez zewnętrzny program: :0 B * .*pheromones | awk -f spamscript spam-suspects Znacznik B stosuje test warunku do zawartości listu. Wszystkie wiadomości zawierające słowo „pheromones” w dowolnym miejscu tekstu są przekazywane w celu przetworze- nia do awk. W tym przykładzie awk uruchamia plik programu o nazwie spamscript, który 6.0. Wstęp 229 wydobywa informacje z wiadomości i zapisuje w pliku o nazwie spam-suspects. Możemy przypuszczać, że administrator tego systemu napisał spamscript, aby wydobywać adresy e-mail z przypuszczalnego spamu. Powyższy przykład przedstawia filtrowanie przez procmail całej treści wiadomości. Do- myślnie procmail sprawdza tylko nagłówki wiadomości. Nagłówkom możemy poświęcić szczególną uwagę w konfiguracji sendmaila, używając niestandardowych zestawów reguł. Niestandardowe zestawy reguł sendmail pozwala definiować niestandardowe przetwarzanie adresów i nagłówków przychodzących wiadomości i udostępnia do tego celu kilka punktów zaczepienia. Do niestandardowego przetwarzania adresów służą: Local_check_relay To jest punkt zaczepienia do zestawu reguł check_relay. Do zestawu reguł Local_ check_relay jest przekazywana nazwa hosta i adres IP hosta, który zainicjował połą- czenie e-mail. Local_check_mail To jest punkt zaczepienia do zestawu reguł check_mail, który przetwarza adres nadaw- cy koperty z polecenia SMTP MAIL From:. Receptura 6.10 zawiera przykładowy zestaw reguł Local_check_mail. Local_check_rcpt To jest punkt zaczepienia do zestawu reguł check_rcpt, który sprawdza adres odbiorcy koperty zdefiniowany poleceniem SMTP RCPT To:. Te zestawy reguł nie zostały zaprojektowane tylko do wykrywania i usuwania spamu; mają szersze zastosowanie. Jednakże te punkty zaczepień zestawów reguł są przydatne do zwalczania spamu. Oprócz tych punktów zaczepienia, wywoływanych ze standarndowych zestawów reguł, możemy wywołać zestaw reguł z definicji nagłówka, aby dokonać własnego przetwarzania nagłówka. Podstawowa składnia polecenia H pliku sendmail.cf definiuje format nagłówków poczty. W podstawowej składni definicja nagłówka zaczyna się od polecenia H, po którym następuje nazwa nagłówka i jego format. Składnia wywołania zestawu reguł z polecenia H wygląda następująco: Hnazwa: $ zestawreguł gdzie nazwa oznacza nazwę nagłówka, a zestawreguł jest zestawem reguł wywoływanym do przetworzenia przychodzących nagłówków o tej nazwie. Ta funkcjonalność może posłużyć do sprawdzania przychodzących nagłówków w celu wykrywania spamu na podstawie informacji w nagłówku. Receptura 6.9 zawiera przykład wykorzystania tej metody. 230 Rozdział 6. Kontrola nad spamem 6.1. Blokowanie spamu za pomocą bazy danych access Problem Ponieważ większość wiadomości przychodzących z konkretnych lokalizacji to spam, należy skonfigurować sendmail tak, by blokował całość pocztyn z tych miejsc. Rozwiązanie Dodaj adresy, które chcesz zablokować, do pliku tekstowego /etc/mail/access. Kluczem w każdym wpisie jest adres spamera, a wartością zwracaną DISCARD — aby odrzucić wia- domość „po cichu”, REJECT — aby odrzucić wiadomość ze standardowym błędem, lub ERROR — aby odrzucić wiadomość z nietypowym komunikatem o błędzie. Za pomocą makemap zbuduj z pliku tekstowego bazę danych typu hash. Następnie utwórz konfigurację sendmaila zawierającą funkcję access_db. Oto wymagane makro FEATURE: dnl Użyj bazy danych access FEATURE(`access_db ) Podobnie jak w przykładzie z receptury 1.8 zrekompiluj plik sendmail.cf, skopiuj nowy plik sendmail.cf do /etc/mail i uruchom ponownie sendmail. Analiza W bazie danych access REJECT, ERROR i DISCARD mogą posłużyć do blokowania niechcia- nej poczty. Poniższy przykład wpisów w bazie danych access blokuje wiadomości z trzech miejsc: example.com REJECT wrotethebook.net ERROR:5.7.1:550 Niepoprawne źródło wiadomości fake.ora.com DISCARD Test telnet pokaże, co te zdalne ośrodki zobaczą w zależności od akcji zdefiniowanych w bazie danych: # telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is ^] . 220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -0400 HELO localhost 250 chef.wrotethebook.com Hello IDENT:UWSRv+Jij66J8vALUBVBECbGPVoU8OQe@localhost [127.0.0.1], pleased to meet you MAIL From: crooks@example.com 550 5.7.1 crooks@example.com ... Access denied 6.1. Blokowanie spamu za pomocą bazy danych access 231 MAIL From: thieves@wrotethebook.net 550 5.7.1 thieves@wrotethebook.net ... Niepoprawne źródło wiadomości MAIL From: junk@fake.ora.com 250 2.1.0 junk@fake.ora.com ... Sender ok QUIT 221 2.0.0 chef.wrotethebook.com closing connection Connection closed by foreign host. Wiadomość z example.com została odrzucona z komunikatem o błędzie „Access denied”, ponieważ wpis dla example.com w przykładowej bazie danych access definiuje dla wia- domości z tej domeny akcję REJECT. Wiadomość z wrotethebook.net została odrzucona z komunikatem o błędzie „Niewłaściwe źródło wiadomości”, który został zdefiniowany w bazie danych access za pomocą polecenia ERROR. Dla odmiany z punktu widzenia zdal- nego systemu wiadomość z fake.ora.com wydaje się zostać przyjęta przez serwer. Aby zobaczyć działanie akcji DISCARD zdefiniowanej w bazie danych access dla fake.ora.com, potrzebny jest test sendmail -bt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter ruleset address check_mail junk@fake.ora.com check_mail input: junk @ fake . ora . com Basic_check_mail input: junk @ fake . ora . com tls_client input: $| MAIL D input: ? ! TLS_Clt D returns: ? ? ! TLS_Clt c A input: ? ! TLS_Clt A returns: ? ! TLS_Clt TLS_connection input: $| ? ! TLS_Clt TLS_connection returns: OK tls_client returns: OK CanonAddr input: junk @ fake . ora . com canonify input: junk @ fake . ora . com Canonify2 input: junk @ fake . ora . com Canonify2 returns: junk @ fake . ora . com canonify returns: junk @ fake . ora . com Parse0 input: junk @ fake . ora . com Parse0 returns: junk @ fake . ora . com CanonAddr returns: junk @ fake . ora . com SearchList input: + From $| F : junk @ fake . ora . ccom U : junk @ D : fake . ora . com F input: junk @ fake . ora . com ? +c From F returns: ? SearchList input: + From $| U : junk @ D : fake . ora . com U input: junk @ ? + From U returns: ? SearchList input: + From $| D : fake . ora . com c D input: fake . ora . com ? + Fromc D returns: DISCARD SearchList returns: DISCARD SearchList returns: DISCARD SearchList returns: DISCARD Basic_check_mail returns: $# discard $: discard check_mail returns: $# discard $: discard /quit W tym teście adres junk@fake.ora.com jest przetwarzany przez zestaw reguł check_mail, który sprawdza adres MAIL From:. Ten zestaw reguł przetwarza adres i zwraca „discard”, co oznacza, że poczta z fake.ora.com będzie odrzucona bez informowania o tym nadawcy. 232 Rozdział 6. Kontrola nad spamem Zobacz również Plik cf/README, rozdział 3. niniejszej książki i wstęp do niniejszego rozdziału dostarczają dodatkowych informacji o bazie danych access. Książka sendmail omawia bazę danych access w podrozdziale 7.5. 6.2. Uniemożliwienie lokalnym użytkownikom odpowiedzi na spam Problem Niektórzy lokalni użytkownicy odpowiadają na listy ze spamem, zachęcając przez to spamerów do dalszego działania. Chcemy skonfigurować sendmail tak, aby powstrzy- mywał spamerów i osoby „wspierające” spam. Rozwiązanie Przed założeniem jakiegokolwiek konta użytkownika zdefiniuj zasady dopuszczalnego użytku które, między innymi, dadzą prawo blokowania wiadomości związanych ze spa- mem — zarówno przychodzących, jak i wychodzących. Upewnij się, że wszyscy użytkowni- cy zgodzą się na te zasady, zanim przyznasz komukolwiek konto użytkownika. Dodaj adresy źródeł spamu, które chcesz zablokować, do pliku tekstowego /etc/mail/access. Użyj znaczników To: i From:, aby uniemożliwić wysyłanie poczty do spamerów i akcep- towanie wiadomości od spamerów. Uruchom makemap, aby zbudować bazę danych typu hash z pliku tekstowego. Utwórz konfigurację sendmaila, która za pomocą funkcji access_db włącza korzystanie z bazy danych access. Wymagane polecenie FEATURE wygląda następująco: dnl Użyj bazy danych access FEATURE(`access_db ) Zrekompiluj plik sendmail.cf, skopiuj nowy plik sendmail.cf do /etc/mail i ponownie uruchom sendmail. Analiza Domyślnie baza danych access stosuje się do adresów źródłowych. Akcje zdefiniowane we wpisach w bazie danych są podejmowane na podstawie źródła wiadomości. W przypadku bazy danych access z receptury 6.1 odrzucane są wiadomości z example.com, wrotethebook.net i fake.ora.com, co pokazują testy w tej recepturze. Na przykład wiadomości od wszelkich 6.2. Uniemożliwienie lokalnym użytkownikom odpowiedzi na spam 233 użytkowników z example.com są odrzucane z błędem „Access denied”. Jednakże baza da- nych accesss z receptury 6.1 nie zapobiega wysyłaniu poczty z lokalnego hosta do domeny example.com. Dodanie znacznika To: do wpisu w bazie danych access powoduje zastosowanie akcji zdefiniowanej we wpisie do adresu odbiorcy pasującego do klucza, natomiast znacznik From: żąda zastosowania akcji do pasującego adresu źródłowego. Baza danych access z receptury 6.1 zmodyfikowana z użyciem znaczników To: i From: wygląda tak: From:example.com REJECT To:example.com ERROR:5.7.1:550 Wiadomości pod ten adres nie są dozwolone From:wrotethebook.net ERROR:5.7.1:550 Niewłaściwe źródło wiadomości To:wrotethebook.net ERROR:5.7.1:550 Wiadomości pod ten adres nie są dozwolone From:fake.ora.com DISCARD To:fake.ora.com ERROR:5.7.1:550 Wiadomości pod ten adres nie są dozwolone Ponieważ dla wpisu From: example.com akcją jest REJECT, wiadomości z tej domeny są odrzucane, jak widać w recepturze 6.1. Po dodaniu wpisu To: wiadomości zaadresowane do example.com również są odrzucane: # telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is ^] . 220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -0400 HELO localhost 250 chef.wrotethebook.com Hello IDENT:UWSRv+Jij66J8vALUBVBECbGPVoU8OQe@localhost [127.0.0.1], pleased to meet you MAIL From: craig@chef.wrotethebook.com 250 2.1.0 craig@chef.wrotethebook.com ... Sender ok RCPT To: crook@example.com 550 5.7.1 crook@example.com ... Wiadomości pod ten adres nie są dozwolone QUIT 221 2.0.0 chef.wrotethebook.com closing connection Connection closed by foreign host. Przy blokowaniu wychodzącej poczty należy szczególnie uważać. Lokalni użytkow- nicy oczekują, że będą mogli komunikować się z kimkolwiek i nie chcą, abyśmy za nich decydowali, z kim mogą rozmawiać, a z kim nie. Zasady dopuszczalnego użyt- kowania, które dają nam takie uprawnienia, muszą powstać, zanim podejmiemy jakiekolwiek działania. I niezależnie od treści tego dokumentu powinniśmy przygo- tować się na skargi. Rozwiązania alternatywne Funkcja blacklist_recipients jest alternatywną metodą blokowania wiadomości wysyłanych do znanych spamerów. Funkcja blacklist_recipients stosuje każdy wpis bez znacznika w bazie danych access do adresów odbiorców. Poniższe wpisy dodane do konfiguracji sendmaila włączają obsługę bazy danych access i stosują ją do adresów odbiorców: 234 Rozdział 6. Kontrola nad spamem dnl Użyj bazy danych access FEATURE(`access_db ) dnl Zastosuj bazę access również do adresów odbiorców FEATURE(`blacklist_recipients ) Funkcja blacklist_recipients jest skuteczna i bardzo łatwa w użyciu. Ponieważ jednak stosuje się do wszystkich wpisów w bazie danych access niezawierających znaczników, to nie jest dostępna w niej kontrola nad konfiguracją umożliwiana przez znacznik To:. Oprócz tego znaczniki stanowią dla samych siebie dokumentację. Każdy, kto spojrzy na przykładową bazę danych access przedstawioną powyżej, widząc znacznik To: i tekst błędu w polu akcji, zrozumie, że wiadomości wysyłane do example.com nie są akceptowane. Zobacz również Rozdział 3. i wstęp do niniejszego rozdziału zawierają dodatkowe informacje o bazie danych access. Książka sendmail omawia bazę danych access w podrozdziale 7.5 i funkcję blacklist_recipients w punkcie 7.5.5. Sekcja Anti-Spam Configuration Control pliku cf/README również omawia ten temat. 6.3. Odczytywanie bazy danych access z LDAP Problem Należy tak skonfigurować sendmail, by odczytywał baznę danych access z serwera LDAP. Rozwiązanie W razie potrzeby zrekompiluj i zainstaluj ponownie sendmail, aby dodać obsługę LDAP do sendmaila, oraz dodaj schemat sendmaila do konfiguracji LDAP w serwerze LDAP. Oba kroki zostały opisane w recepturze 1.3.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

sendmail. Receptury
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: