Listy dystrybucyjne i procmail
Powszechne narzekanie na ilość zalewającego nas spamu stało się banałem. Automaty rozsyłające niechciane wiadomości działają nieustannie, dość skutecznie zalewając skrzynki pocztowe. Istnieje wiele metod walki z opisywanym zjawiskiem. Ja jednak chciałem skupić się na wybranym przypadku. W większości firm istnieją adresy zbiorowe, za pomocą których tworzy się proste listy dystrybucyjne, np. wysłanie wiadomości na adres “biuro@firma.com” powoduje automatyczne rozesłanie jej do kilku adresatów. Nie trzeba długo się zastanawiać aby dojść do wniosku, że taki adres może również ułatwiać rozsyłanie spamu! Co zrobić aby zabezpieczyć się przed tym zjawiskiem? Poniżej zamieściłem opis dość prostej i skutecznej metody.
Przede wszystkim zakładam, że na serwerze zainstalowany jest pakiet procmail, który umożliwi przetwarzanie przychodzących wiadomości. Na temat pisania reguł dla procmaila można znaleźć dużo materiałów w sieci np. tutaj. Nadaje się do wielu zadań i pozwola naprawdę dodać nowe funkcje do serwera poczty sam nie będąc jego integralną częścią. Ale do rzeczy. Żeby zabezpieczyć adres zbiorowy tworzymy w katalogu domowym dla konta “biuro” (kontynuując przykład z pierwszego akapitu) plik “.procmailrc”
touch .procmailrc
Następnie umieszczamy w nim mniej więcej taką zawartość:
LOGFILE=$HOME/.procmail_log
:0
# Przepuszczaj wiadomosci jesli pole nadawca zawiera ciąg @firma.com.
* ^From:.*@firma\.com
# Odfiltruj wiadomosci od daemona.
* ! ^FROM_DAEMON
# Odfiltruj wiadomosci zapetlone.
* ! ^X-Loop: EFa1bie2reifiuXeiveizae2
{
:0fwh
# Stempluj naglowek kazdej przetwarzanej wiadomosci.
| formail -A"X-Loop: EFa1bie2reifiuXeiveizae2"
:0
# Wyslij wiadomosc na adresy pobrane z pliku ".lista".
!`cat .lista`
}
:0
# Cala reszte przekieruj w kosmos!
/dev/null
A teraz po kolei. Przede wszystkim ograniczamy zbiór nadawców do tych, którzy mają w polu “Nadawca” ustawione “@firma.com“. Oczywiście spamerzy również mogą podszyć się pod ten adres (zmiana wartości pola “Nadawca” jest łatwa). Jednak z mojego doświadczenia wynika, że to proste ograniczenie pozwala znacznie ograniczyć ruch. Pozostałe wiadomości odrzucamy przekierowując je na “/dev/null”.
Wiadomość, która spełnia podstawowy warunek zostanie przetworzona. Zanim jednak tak się stanie dobrze jest sprawdzić 2 warunki:
- Czy nie jest to przypadkiem wiadomość od daemona systemowego. Bardzo pożyteczny warunek w sytuacji gdy dystrybuujemy wiadomość na konto, które nie istnieje (np. administrator usunał je bez poinformowania nas o tym). Zabezpiecza przed zapętleniem wiadomości.
- Czy nie jest to wiadomość zapętlona. Np. użytkownik docelowy ustawił sobie autoodpowiedź, wówczas będzie automatycznie odpowiadał na wiadomość z listy dystrybucyjnej (rozsyłając tym samym autoodpowiedź do wszystkich jej odbiorców). Lista z kolei będzie odsyłać ją z powrotem i tak w kółko. Warto zwrócić uwagę, że aby sprawdzić czy wiadomość nie była już raz przetwarzana (czyt. jest zapętlona) trzeba ją oznaczyć stemplem w nagłówku.
Jeżeli wymienione warunki zostały spełnione, możemy z czystym sumieniem rozesłać wiadomość do użytkowników wymienionych w pliku “.lista”, która przykładowo ma postać:
user1@firma.com user2@firma2.com user3@firma3.com
MAG