W notce tej dowiesz się jak konfigurować wirtualne domeny oraz konfigurację antywirusa.
Wirtualne domeny
Najpierw należy dopisać wirtualną domenę do konfiguracji serwera DNS. Następnie tworzymy mapę wirtualnego serwisu (możemy to utworzyć na dwa sposoby: Postfixa i Sendmaila).
Mapa może mieć postać (postać postfixa)
ziutus.com #postfix-style linux@ziutus.com ziutus@localhost
Następnie informujemy Postifxa dopisując do pliku /etc/postfix/main.cf informacje w którym pliku są zapisane mapy. Dokonujemy tego przy pomocy polecenia:
virtual_maps = hash:/etc/postfix/virtual
Nadpisywanie nagłówków from
Należy także nadpisywać nagłówki from. Robimy to przy pomocy mapy canonical, w ten sposób uzyskamy możliwość ukrywania prawdziwego adresu (na serwerze) adresem domeny wirtualnej. Plik mapy ma bardzo prostą składnie, zapisujemy w nim co zamieniamy czym, np.
marek@localhost marek@ziutus.com
następnie tworzymy z mape z tego pliku:
postmap /etc/postfix/canonical
i infouumjemy demona postfix o istnieniu mapy umieszczając dyrektywe
canonical_maps = hash: /etc/postfix/canonical.db
Następnie nakazujemy demonowi odczytać ponownie ustawienia poleceniem /etc/init.d/postfix reload i już. Wszystko działa. Możemy wykonać test wysyłając maila między dwoma testowymi użytkownikami.
Dołączanie programu antywirusowego
Postfix nie ma możliwości samodzielnego sprawdzania czy w wiadomości nie ma wirusów. Można jednak włączyć w proces przesyłania wiadomości dodatkowy program, który będzie to robił. Więcej dowiesz się w lekcji poświęconej Amavisd-new.
Postfix i bazy RBL jako sposób na zmniejszenie ilości spamu
Bazy RBL są to udostępniane w Internecie bazy serwerów, które rozsyłają spam. Postfix może połączyć się z taką bazą (działają one przeważnie na zasadzie DNSów) i jeżeli wysyłający komputer jest umieszczony na takiej liście, to automatycznie odmawia przyjęcia od niego listu.
Konfiguracja Postfiksa by korzystał z baz RBL w obu wersjach jest bardzo prosta. W przypadku wersji 1.x (już praktycznie nieużywanych), należy w zmiennej maps_rbl_domains podać nazwy serwerów RBL z których będziemy korzystać a następnie w zmiennych smtpd_client_restrictions i smtpd_recipient_restrictions wprowadzić ich wykorzystywanie.
Postfix wersja 1.x : maps_rbl_domains = relays.ordb.org, inputs.orbz.org smtpd_recipient_restrictions = reject_unknown_client, permit_mynetworks, reject_maps_rbl, check_relay_domains smtpd_client_restrictions = reject_unknown_client, reject_maps_rbl
W przypadku Postfiksa w wersjach 2.x jasno definiujemy w zmiennej smtpd_client_restrictions od razu z jakich serwerów RBL korzystamy i w jakiej kolejności (ma to wzgląd wydajnościowy, jako pierwszych lepiej użyć bardziej restrykcyjnych).
Postfix wersja 2.x : smtpd_client_restrictions = hash:/etc/postfix/access_map, reject_rbl_client relays.ordb.org, reject_rbl_client bl.spamcop.net, permit
W celu sprawdzenia czy mapy działają poprawnie, łączymy się z lokalnym Postfixem i wysyłamy list z adresu 127.0.0.2. Obie mapy traktują go (w celach testowych) jako zakazane. Jeżeli dostaniemy komunikat odmowny wszystko działa poprawnie.
Praktyka wykorzystania RBLi
Każdy kij ma dwa końce, z jednej strony restrykcyjne RBLe (np. www.spamcop.net) w znaczącym stopniu zmniejszają ilość spamu napływającego do użytkowników serwisu, z drugiej strony mogą odrzucać wiadomości z serwerów nie radzących sobie z problemem spamu (np. Wirtualna Polska). ?agodne RBLe mają w swoich bazach jedynie najsłynniejszych spamerów, więc mało odrzucają spamu ale również nie blokują wiadomości, które powinny dotrzeć do użytkowników. Jak to zawsze w życiu bywa, coś za coś.
Mam ostatnio przyjemność zarządzania serwerem pocztowym z ponad tysiącem użytkowników. Efekt skorzystania z bardzo restrykcyjnych baz RBL został pozytywnie przyjęty przez użytkowników. Ilość spamu docierającego do użytkowników znacząco spadła. Niedogodności związane z nie przyjmowaniem wiadomości od pewnych serwerów zostały przysłonięte znacznym zwiększeniem komfortu korzystania z konta pocztowego…
Internet
Jest kilka organizacji walczących z spamerami i open relay-ami. Kilka najsłynniejszych to:
- http://www.spamcop.net Bardzo restrykcyjna ale i wygodna baza RBL. Istnieje wytyczna do Squirrmaila pozwalająca użytkownikom od razu do bazy zgłaszać spam.
- http://www.sorbs.net/
TLS
Jak wygenerować certyfikaty przy pomocy openssl możesz się dowiedzieć z innego posta: Tworzenie certyfikatów SSL – krótko, miło, treściwie albo OpenSSL – Tworzenie certyfikatu, edycja, narzędzia pomocnicze .
Jak już je wygenerujesz, dodaj do pliku /etc/postfix/main.cf:
######## TLS smtpd_use_tls=yes smtpd_tls_auth_only=no smtpd_tls_key_file= /etc/ssl/certs/pem.pem smtpd_tls_cert_file=/etc/ssl/certs/pem.pem smtpd_tls_CAfile=/etc/ssl/certs/cacert.pem smtpd_tls_loglevel= 1 smtpd_tls_recived_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source=/dev/urandom
W przypadku problemów zgłaszanych przez użytkowników należy sprawdzić czy ich programy klienckie obsługują szyfrowanie,
przykładowo Avast Antyvirus w przeszłości nie potrafił sobie z nim poradzić.
SASL z wykorzystaniem mechanizmu PAM
SASL czyli Simple Authentication and Security Layer, pozwala kontrolować kto wysyła pocztę przez nasz serwer. Pomysł nie jest nowatorski ale w
miarę skuteczny. Otóż każdy wysyłający wiadomość musi podać swój login i hasło. Inaczej nic nie wyśle..
Instalujemy potrzebne oprogramowanie
yum install cyrus-sasl-plain.x86_64
Dodajemy do /etc/postfix/main.cf wpisy
###sasl with PAM smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous # put into header information about authorized user, which sent email smtpd_sasl_authenticated_header = yes
Dodajemy także restrykcje dotyczące kto może wysyłać wiadomości email (dodajemy permit_sasl_authenticated):
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client dnsbl.sorbs.net,
reject
I restartujemy serwer Postfix:
#/etc/init.d/postfix restart
Testujemy mechanizm autoryzacji SASL
[root@ziutusLinux1 sasl2]# testsaslauthd -s smtp -u ziutus -p XXX 0: OK "Success."
Testujemy, czy nasz Postfix pozwala na autoryzacje
Najpierw generujemy string, którego użyjemy w połączeniu:
echo -ne '\000username\000password' | openssl base64
Następnie łączymy się telnetem do naszego Postfiksa i wydajemy polecenie auth plan WygenerowanyString.
[root@ziutusLinux1 sysconfig]# telnet 127.0.0.1 25 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 ziutusLinux1.localdomain ESMTP Postfix ehlo localhost 250-ziutusLinux1.localdomain 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN auth plain AHppdXR1cwB6dXV6MDB6dXV6 235 2.7.0 Authentication successful
I już 🙂
Więcej informacji
Jak sprawić by Postfix autoryzował się na zewnętrznych serwerach
smtp_sasl_auth_enable = yes smtp_sasl_password_maps = /etc/postfix/sasl/password_map
- smtp_sasl_password_maps mówi Postfixowi która mapa zawiera wychodzące informacje autoryzujące. To nie to samo co sasldb; sasldb nie może zostać użyte do autoryzacji połączeń wychodzących. Przykładowo może być „hash:/etc/postfix/sasl_passwd”.
- smtp_sasl_security_options zawiera te same słowa kluczowe co smtpd_sasl_security_options opisane wyżej.
Postfix i IPv6
Postfix od wersji 2.2 ma wbudowaną obsługę Protokołu IPv6.
Jeżeli chesz wyłaczyć obsługę IPv6, ustaw zmienna inet_protocols na ipv4:
inet_protocols = ipv4
Więcej informacji o sposobie konfiguracji programu pod wymagania tego protokółu znajdziesz na stronie http://www.postfix.org/IPV6_README.html.