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.

"Relay access denied"

Dwa możliwe scenariusze występowania tego komunikatu:

1) jeżeli łączymy się do naszego serwera i wysyłamy pocztę w świat to oznacza, że klient poczty nie wysłał poprawnego loginu i hasła lub nie działa w ogóle SASL lub nasze IP nie jest na liście mynetworks - zaufanej liście IPków, które mogą wysyłać pocztę bez autoryzacji.

2) jeżeli wysyłamy pocztę z zewnętrznego serwera do naszego serwera i występuje ten komunikat - to oznacza, że nasz serwer nie ma poprawnie skonfigurowanej domeny - myśli, że domena leży gdzie indziej a ponieważ zewnętrzny serwer nie należy do zaufanych to on nie będzie relayował poczty.

Rekord MX

przydarzył mi się ostatnio ciężki przypadek admina, który wysyłając pocztę z zewnętrznego serwera do swojego serwera otrzymywał komunikat błędu. Oglądając logi stwierdziłem, że nic w nich nie ma. I wcale nie chodzi o to, że "nic ciekawego". W logach naprawdę nic nie było. Okazało się, że w ogóle nie skonfigurował rekordu MX dla swoje domeny i poczta leciała na zupełnie inny serwer, który to był odpowiedzialny za komunikat błędu.

Mieszanie ze sobą użytkowników/domen/aliasów wirtualnych 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

zazwyczaj jest to "localhost", "localhost.localdomain" lub sama nazwa hosta - bez domeny np. "mail"

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.

Ostatnio mi się trafił przypadek: email z mojego serwera trafiał na serwer weryfikujący nadawcę. Mój serwer stosował greylisting zatem na próbę weryfikacji odpowiedział "450 wróć później". Zatem serwer odbiorcy powiedział "450 weryfikacja nie powiodła się". No niby ok, mój serwer za 5 minut ponowił próbę dostarczenia emaila. Teoretycznie rzecz biorąc tamten serwer powinien znowu zweryfikować nadawcę, wtedy mój serwer odpowiedziałby "200 OK", nadawca okazałby się zweryfikowany i email przyjęty. W praktyce okazało się, że tamten serwer trzyma to "450 wróć później" w keszu i mój serwer próbował dostarczyć emaila przez trzy godziny zanim ten jego kesz się wyczyścił i ponownie została podjęta próba weryfikacji nadawcy. No i Bardzo Ważny Email na trzy godziny utknął niepotrzebnie w kolejce.

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

w postfixie 1.x używane było permit_auth_destination, w postfixie 2.x jest używane reject_unauth_destination. Upgrade postfixa nie jest zatem błahą sprawą - wymaga nieco matematyki, konkretnie logiki, zwłaszcza o operatorze negacji. W P 1.x permit_auth_destination w łańcuchu daje się na końcu a zaraz potem reject. Przy reject_unauth_destination najpierw daje się permity, potem rejecty (w tym wspomniane reject_unauth_destination) i na końcu permit. IMHO przy permit_auth_destination jest większe prawdopodobieństwo zrobienia błędu i zrobienia sobie Open Relaya.

Nieaktualne RBLe

Co jakiś czas trzeba sprawdzać czy stosowane RBLe jeszcze żyją, nagminnym przykładem jest stosowanie list.dsbl.org, rangers.eu.org etc. nawet kilka lat po tym jak przestaną one istnieć. Postfix brakującego RBLa zgłasza takim warningiem:

RBL lookup error: Host or domain name not found. Name service error for name=

mail loops back to myself

czyli DNS wskazuje, że to lokalny serwer powinien odebrać pocztę ale domena nie jest wpisana w $mydestination albo $virtual_mailbox_domains. Trzeba dopisać domenę albo rozwiązać problem z DNSami.

revDNS

Należy zadbać o to aby IP z którego postfix wysyła emaile miało revDNS i to w dodatku taki, który z powrotem rozwiązuje się na ten sam IP. U nas w logach można zauważyć pełno takich komunikatów:
hostname *: No address associated with hostname
address not listed for hostname *
z reguły są to połączenia od spamu jednak od czasu do czasu zdarza się źle ustawiony serwer. Właśnie ze względu na takich niedoinformowanych postmasterów postfix wprowadził reject_unknown_reverse_client_hostname, które uwala tylko te połączenia, które pochodzą od klientów z brakującym revDNSem (a nie błędnym jak w przypadku reject_unknown_client_hostname). W polskich warunkach uwalanie za brak revDNSa może być problematyczne.
Aha, warto by zadbać aby revDNS nie wyglądał na dynamiczny - SORBS ma FAQ na ten temat.

odpowiedni revDNS i odpowiednie EHLO

po za tym, co wspomniałem wcześniej warto by zadbać aby te nazwy nie zawierały adresu IP. Dla przykładu:
4.3.2.1.cośtam.tld - taki hostname jest uznawany za dynamiczny, nawet jeżeli to będzie 4.3.2.1.static.cośtam.tld to taka nazwa znacząco wpływa na score spamassassina czyli prawdopodobieństwo zablokowania emaila w filtrach antyspamowych.

niektóre pliki się postmapuje a niektóre nie

Postmap przekształca plik tekstowy w indeksowaną bazę danych. Powstaje plik o takiej samej nazwie i rozszerzeniu .db. Postmapuje się hasze, Mapy pcre, cidr, mysql - nie potrzebują odpalania na nich postmapa.
Komunikat w logach: postmap: fatal: open database .db: no such file or directory
Odpalać postmapa trzeba po każdej zmianie w pliku tekstowym, inaczej w logach będzie:
warning: database /etc/postfix/sender_checks.hash.db is older than source file /etc/postfix/sender_checks.hash

setki maili Failure notice

gratulacje, prawdopodobnie masz włamanie na konto z powodu trywialnego hasła typu "123456"

Serwery administrowane myszką

Zazwyczaj administrowanie takiego serwera polega na zakładaniu userów. Admin nie ma zielonego pojęcia gdzie są logi (WTF are logi?!), co się aktualnie dzieje z serwerem, dlaczego emaile nie dochodzą, dlaczego adres IP serwera pojawił się na czarnych listach. W momencie pojawienia się problemów admini najpierw szukają po sieci cudownego środka na porost włosów a następnie usiłują dopasować ten środek do burdelu panującego na serwerze. Robi się jeszcze większy burdel, po czym następuje szukanie pomocy na forach. Szukanie pomocy na forach polega na wysłaniu posta "Pomóżcie, bo nie działa" i do pracy przystępują wróżki ze szklanymi kulami. Jak czasami trafiam na jakąś taką dyskusję to stwierdzam, że niektóre wróżki to chyba wypiły większą część szlachetnego płynu wypełniającego oryginalnie szklane kule, zmniejszyła się zdolność wykrywania problemów za to wzrosła elokwencja...

Najwyższy poziom prezentuje grupa usenetowa pl.comp.mail.mta - przesiadują tam najlepsi fachowcy od serwerów poczty po pierwsze dlatego, że jest to najstarsze miejsce w którym rozmawia się o poczcie a po drugie dlatego, że jest to grupa dedykowana serwerom poczty.

Z moich doświadczeń wynika, że admini serwerów Exchange powinni zostać wysterylizowani, aby ich geny nie przenosiły się dalej. Serio mówię - przeciętny postfixowy / eximowy żółtodziób wie więcej o działaniu poczty niż większość adminów Exchange. Następni w kolejności są właściciele filtrów typu barracuda - za backscatter jakie ich systemy poczty generują.

Bezmyślne wkopiowanie moich (lub kogokolwiek) konfigów.

Na mojej stronie "konfiguracja postfixa" podaję po kolei rożne opcje do wklejenia do konfiga. Dużo osób w ogóle nie czyta mojego tekstu tylko od razu przechodzi bezmyślnego wkopiowania plików z mojego przykładowego konfiga do swojego systemu. Po czym to oczywiście nie działa. Zwłaszcza, że już mają śmietnik bo eksperymentowali z innymi tutorialami i też im się nie udało.

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.

Komentarze: