Postfix main.cf czyli kolejność ma jednak znaczenie
Przez wiele lat konfigurowałem rozmaite serwery poczty opierając się o sprawdzony serwer Postfix w tandemie z Debianem. Były to konfiguracje bardzo proste, średnio złożone i takie, które wymagają posiedzenia nad problemem dłużej. Wykorzystywałem Postfix natywnie i w połączeniu z gotowymi skryptami (np. polecanym iRedMail). Przyznam, że nigdy nie zawiódł i wydawał się być dość prosty w obsłudze przy jednocześnie rozbudowanych opcjach ustawień. Do czasu aż trafiłem na problem, który zatrzymał mnie w miejscu na parę godzin. O co chodzi? Otóż w każdej sieci znajdzie się urządzenie, komputer, router może termometr IP, które będzie chciało wysyłać emaile z komunikatami. I zazwyczaj mają one wbudowaną obsługę autoryzacji dla połączeń SMTP. Jedna raz na jakiś czas trafi się egzamplarz, który za żadne skarby świata nie potrafi się kulturalnie przedstawić naszemu Postfixowi. Wówczas nie pozostaje nic innego jak zrobić małe obejście i dopuścić urządzenie do wysyłania emaili bez żadnych ograniczeń. Wiem, że nie powinniśmy tak nigdy robić ale czasem trzeba. W Postfixie służy do tego opcja (na przykładzie adresu 10.10.10.10):
mynetworks = 127.0.0.1 10.10.10.10
która spowoduje, że wymienione po kolei hosty stają się uprzywilejowane. Czy zawsze to zadziała? W tym właśnie tkwi sedno sprawy, że nie! Otóż jeżeli w naszej konfiguracji stosujemy różne ograniczenia (a jak wspomniałem Postfix jest bogaty w możliwości) czyli np. zastosujemy dyrektywę smtpd_recipient_restrictions to kolejność jej atrybutów zaczyna mieć znaczenie. Czyli np. kod:
smtpd_recipient_restrictions = permit_mynetworks reject_unknown_recipient_domain reject_non_fqdn_recipient
jest prawidłowy bo atrybut permit_mynetworks jest pierwszy na liście. Jednak ten sam kod zapisany:
smtpd_recipient_restrictions = reject_unknown_recipient_domain reject_non_fqdn_recipient permit_mynetworks
jest już nieprawidłowy bo kolejność ma jednak duże znaczenie. Reguła ta obowiązuje dla wszystkich dyrektyw, dla których możemy użyć atrybutu permit_mynetworks.
MG
Tagi: konfiguracja, Linux, poczta elektroniczna, Postfix, serwer
Jak powszechnie wiadomo nie wynaleziono jeszcze bardziej popularnej usługi do transferu plików niż FTP. Być może większość administratorów wolałaby korzystać z innych rozwiązań ale tak się składa, że znają prawie wszyscy użytkownicy i to oni z reguły wymuszają stosowanie FTP. Podstawowy problem w tym przypadku to brak szyfrowania transmisji co przede wszystkim oznacza przesyłanie haseł jawnym tekstem. Jednak mając gotowy serwer z Linuxem oraz dostępem zdalnym po SSH można pokusić się o przygotowanie serwera SFTP, który zachowując większość funkcji FTP będzie zabezpieczał odpowiednio nasze połączenia. Co więcej jeśli ktoś dotychczas korzystał z bardzo popularnych programów typu 
Całkiem niedawno instalowałem po raz kolejny serwer poczty dla klienta. Niestety wsparcie dla mojego ulubionego Debiana Squeeze skończyło się w kwietniu tego roku dlatego postanowiłem od razu pominąć dystrybucje Wheezy i skorzystać z Jessie. W jednym ze 
Domena MS Active Directory umozliwia przechowywanie profilu użytkownika w postaci tzw. Roaming Profile. Oznacza to, że przede wszystkim dane użytkowników mogą byc składowane na serwerze i umieszczone w odpowiednim współdzielonym katalogu. Główną zaletą takiego rozwiązania (pominę tym razem wady) jest umożliwienie pracy z każdej końcówki w domenie ponieważ po zalogowaniu profil użytkownika jest przesyłany na stację roboczą. Zaś podczas pracy system dba o synchronizację jego zawartości z serwerem. Brzmi całkiem nieźle i powiedzmy, że generalnie się sprawdza.
Jeśli chcemy precyzyjnie zarządzać demonami systemowymi uruchamianymi w trakcie startu sytemu to pakiety rcconf i sysv-rc-conf mogą okazać niezastąpionym narzędziem. Wyobraźmy sobie, że administrujemy sewerem Debian bez powłoki graficznej. Aby dodać lub usunąć usługę systemową do listy procesów startowych możemy skorzystać z dobrze znanego skryptu update-rc.d. Niestety, zdarza się, że podczas jego użycia napotkamy błędy związane ze skryptami startowymi. Co można zrobić w takiej sytuacji? Jeżeli zależy nam na czasie, proponuje zainstalować z repozytorium odpowiednie narzędzia:
Dzisiaj krótki, wakacyjny wpis dotyczący błędu związanegoz konfiguracją obsługi IMAP za pomocą Dovecot. W tandemie ze standardowo skonfigurowanym Postfixem, gdy zdecydowaliśmy się przechowywać pocztę w formacie mbox w katalogu /var/mail/ przy próbie pobrania poczty za pomocą dowolnego programu pocztowego (np. Thunderbird) w pliku /var/log/mail.log mogą pojawić się następujace błędy: