Najczęstsze błędy popełniane przez zielonych postmasterów.

Umieszczanie w mynetworks całego zestawu IPków.

w mynetworks umieszcza się tylko i wyłącznie adresy IP, którym się ufa:

mynetworks = 127.0.0.1/32
mynetworks_style = host

Jeżeli ufasz wszystkim windowsom a raczej wszystkim blondynkom w sieci lokalnej to możesz ją sobie tam umieścić. Do czasu pierwszego lepszego wirusa będziesz miał spokój.

Umieszczanie w mydestination lub relay_domains zbyt wielu domen.

Tam powinny być tylko te domeny, które są obsługiwane lokalnie na serwerze. Największym lamerstwem jest na przykład umieszczenie tam całej "pl".

mydestination = lemat.priv.pl
relay_domains = $mydestination

Zbyt "szeroki" parametr relay_domains powoduje powstanie Open-Relay, co będzie widać w ciągu kilku dni jak spamerzy zatkają całkowicie łącze.

Mieszanie ze sobą użytkowników/domen/aliasów virtualnych i użytkowników/domen/aliasów systemowych.

opcje virtual* są dla użytkowników virtualnych, takie opcje jak alias_maps, mydestination, transport_maps są dla użytkowników systemowych. Albo dany wpis jest systemowy albo jest virtualny. Albo - albo.

Podczas startu postfixa pojawia się komunikat: "warning: do not list domain domena.pl in BOTH mydestination and virtual_mailbox_domains"

Właściwe OK na właściwym miejscu

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,

pomiędzy smtpd_recipient_restrictions a reject_unauth_destination nie wolno nam wstawiać list nadawców, których wynikiem może być "OK"

Jeżeli tak zrobimy to w najbliższym czasie wykorzysta to jakiś wirus podszywając się pod nadawcę.

Właściwe 55X na właściwym miejscu

Postfix odbijając maila z jakiegoś powodu może odbijać go błędem tymczasowym 4xx lub stałym 5xx. Moim zdaniem niektóre opcje są defaultowo ustawione źle - nawet pomijając tu fakt, że Wietse pozwala tym samym zielonym postmasterom na przetestowanie swojego softu. Ja polecam od razu ustawić te opcje w poniższy sposób:

unknown_local_recipient_reject_code = 550
unknown_hostname_reject_code = 550
unknown_address_reject_code = 550
unknown_client_reject_code = 550

Wtedy nadawca od razu otrzyma maila zwrotnego "że coś jest nie tak" a nie po pięciu dniach.

Odpowiednie HELO/EHLO.

Postfix wysyłając pocztę musi się przedstawiać odpowiednim helo/ehlo. Czyli nazwą, którą da się rozwiązać na adres IP.

smtp_helo_name = $myhostname
zawartość $myhostname jest defaultowo równa wartości zwracanej poleceniem hostname

Jeżeli serwer odbiorcy sprawdza poprawność HELO to w przypadku błędnego ustawienia pojawia się w zwrotkach komunikat "Helo command rejected: Host not found;"

Odpowiednie $myorigin

Wysyłając pocztę z linii poleceń, lub na przykład używając funkcji mail() z PHP adres nadawcy jest konstruowany z loginu aktualnie zalogowanego użytkownika (np. apache) oraz $myorigin po prawej stronie od małpy. Warto zadbać, aby w przypadku błędów w dostarczeniu takiej wiadomości wygenerowana zwrotka trafiła do nadawcy z właściwej domeny i została przeczytana przez człowieka.

Weryfikacja nadawcy

Postfix potrafi połączyć się z serwerem MX nadawcy listu, wykonać dialog SMTP pozwalający na zweryfikowanie czy nadawca maila istnieje i na tej podstawie przyjąć (lub nie) maila do siebie. I wszystko byłoby fajnie ale:

1. Spamerzy używają istniejących adresów email
2. Greylisting zwracający 450

Na tej podstawie śmiem twierdzić, że taka weryfikacja nadawcy jest bezużyteczna.

Weryfikacja odbiorcy

Jeżeli odbiorca jest lokalny, to postfix w domyślnej konfiguracji nie przyjmie listu jeżeli odbiorca nie istnieje. Natomiast jeżeli odbiorca znajduje się na innej maszynie (na przykład w konfiguracji dual-mta, gdzie postfix dostarcza maila do wewnątrz sieci na przykład do exchange lub lotusa albo gdy postfix jest zapasowym MX dla domeny) trzeba powiedzieć postfixowi, który odbiorca istnieje. I można to zrobić na kilka sposobów:

1. trzymać lokalnie bazę odbiorców - wymaga kopiowania bazy z głównego serwera po każdej jej zmianie.
2. postawienie serwera LDAP, oba serwery wtedy go odpytują
3. użycie reject_unverified_recipient (opisane na stronie http://www.postfix.org/ADDRESS_VERIFICATION_README.html)
   postfix połączy się podczas odbierania listu z serwerem właściwym dla odbiorcy i go zweryfikuje. Problemem jest oczywiście greylisting, dlatego na serwerze odbiorcy trzeba nasz serwer whitelistować.

Stawianie serwera poczty na tym samym IP co NAT

(nie dotyczy to postfixa, ale to dosyć ważne)
Jeżeli serwer poczty jednocześnie robi za ruter a nie kontroluje on ruchu wychodzącego w świat z sieci lokalnej to może się okazać, że jakiś zawirusowany komputer w sieci lokalnej spowoduje umieszczenie adresu IP na czarnej liście np. CBL, Spamcop. I wtedy będzie bardzo trudno coś wysłać w świat. Rozwiązaniem jest ipt_recent lub jakieś smtp_proxy.

Komunikaty w zwrotkach:
Client host [1.2.3.4] blocked using sbl-xbl.spamhaus.org; http://www.spamhaus.org/query/bl?ip=1.2.3.4

Naleciałości z postfixa 1.x

Nieaktualne RBLe

mail loops back to myself

revDNS

Podsumowanie

Jeżeli nie wiemy do czego służy dana opcja to jej nie dotykamy. Jeżeli nie wiemy jak działa serwer pocztowy, to go nie instalujemy. Nie wolno eksperymentować na sprzęcie podłączonym do netu. Lepiej znaleźć admina z prawdziwego zdarzenia i mu to zlecić niż zepsuć i narzekać. Spamerzy wprost uwielbiają pozycję dominującą podczas stosunku analnego z lamerami. Chrońcie swój tyłek.