vermin.eu.org

Musiałem dziś odwiedzić pocztę. Czasem trzeba wysłać jakieś przesyłki pocztowe - kartki, listy, faktury. No więc poszedłem tam dziś aby wysłać 5 listów - potrzeba do tego 5 kopert. Niestety, koperty to coś, czego na poczcie nie ma. Tak - nie ma. Są niedostępne, nie istnieją… do nowego roku. Po nowym roku będą - zostały zabrane upstream bo jest “inwentaryzacja”.
Zrobiłem ostrą awanturę i te moje 5 kopert C5 się znalazło - niemniej był to wyjątek bo jakaś miłą urzędniczka znalazła swój prywatny stash. Dla mnie osobiście, biorąc pod uwagę wspaniały image poczty polskiej w ostatnich czasach, to totalna porażka. Jak można zawieszać biznes na kilka dni z tak błachego powodu? Dlaczego placówki nie mogą mieć zapasu pewnych rzeczy - skoro znaczki im nie “wyszły” to dlaczego skończyły się koperty? Zawsze idea “remanentów” w świecie, gdzie okazje biznesowe dzieją się wciąż, gdzie wszystko jest powinno być przetwarzane on-line dzieją się takie rzeczy. No ale cóż, batche w bankach też wyłączają serwery na co najmniej godzinę dziennie (inteligo mniej więcej 1-2 w nocy)… Tak jakby nie było innych możliwości technicznych.

Ciekawe co zrobią jak skończą się znaczki…

WSS podał odnośnik do artykułu na Performance Blog i opatrzył go tytułem “Pliki PST w sieci to zły pomysł“. Cóż - ja mam przeciwne zdanie, które postaram się tu (bo gdzie?) przedstawić.

Po pierwsze warto sobie zdać sprawę kiedy i dlaczego używa się sieciowych plików PST. Sam plik PST przechowuje dane (głównie pocztowe) użytkownika. Jest to plik skomplikowany w swej strukturze plik, który bardzo lubi nabierać wielkości. Wyobraźmy sobie teraz małą sieć w firmie. Zazwyczaj użytkownicy korzystają ze swojego komputera, niemniej czasem zdarza im się przesiąść na cudzy komputer i potrzebują tam swoich danych. Na szczęście wprowadziliśmy małą domenę NT (dowolna platforma) i mamy roaming profiles, więc dane użytkownika wędrują zanim… oprócz danych Microsoft Outlook, który jest umieszczony w %USERPROFILE%\Ustawienia lokalne\Dane aplikacji\Microsoft\Outlook. Ponieważ są to ustawienia lokalne to plik ten niestety się nie przerzuca na serwer, więc podłączając się do nowej stacji nie mamy do niego dostępu.

Wykonujemy drugi krok, przerzucamy plik do lokalizacji, która się synchronizuje… I to jest największy błąd, bo ładowanie/zamykanie profilu trwa wieki ze względu na konieczność synchronizacji danych. Żeby się tego pozbyć wrzucamy pliki do udziału sieciowego, konfigurujemy na nim uprawnienia, przekonfigurowujemy outlooka odnośnie umiejscowienia jego pliku magazynowego i voila. Działa. Działa szybko i sprawnie - poczta dostępna z każdego komputera, w jednej lokacji. Dzięki temu łatwo je zbackupować… ale nie tylko! Możemy się do tych plików podłączyć i przeprowadzić ich defragmentację, archiwizację czy też inną operację administracyjną o jakiej sobie pomyślimy.

Ok, dlaczego wobec tego takie halo? Otóż faktycznie, jeśli te pliki są duże, jeśli nasza sieć jest rozbudowana tak, że mogą pojawić się poważne przekłamania podczas transmisji i przede wszystkim - jeśli takich użytkowników jest dużo to faktycznie - tylko serwer Exchange. Ale pojmowanie małej sieci w wersji amerykańskiej (nawet nie 200 stacji z przykładu ale chociażby 50) a polskiej (10 stacji) to jednak jest różnica. Jeśli kogoś stać na tyle licencji (i administratora do tego) to wydatek na Exchange nie powinien być dla niego aż takim obciążeniem (że o SBS nie wspomnę)…
Niemniej jesteśmy na rynku polskim - i tu w małej sieci pliki PST na zdalnym udziale oraz administrator, który wie jak nimi zarządzać to wszystko co firmie jest potrzebne. Szczególnie jak jest do tego AD i firmowa książka adresowa to Exchange jest wręcz zbytkiem (chociaż to naprawdę kawał fajnego produktu jest). A że jest to niewspierane przez MS? Cóż - przecież tego Exchange trzeba ludziom sprzedać

Pech chciał, że mój serwer pocztowy akurat miał drobny problem ze sobą i MS Outlook 2003 nie mógł wysłać wiadomości z outboxu. Wiadomości, która notabene w nim nie istniała. Nie istniała, a outlook wciąż ją wysyłał. lista wiadomości do wysłania pusta, a outlook wciąż pisze - wysyłanie wiadomości 1z 1… Na szczęście wiem jaka to wiadomość - raport przeczytania wiadomości. Przez chwilę już obawiałem się, że wredny outlook chce wysłać wiadomość, że nie przeczytałem wiadomości (odrzucenie raportu potwierdzenia), ale na szczęście nie był aż tak wredny.
Ok - jak się tego pozbyć? Cóż - google pomogły mi znaleźć stronkę ze szczegółową receptą. Wystarczył outlookspy, (programik zresztą przydatny do śledzenia co w outlokou słychać, pokazuje jak bardzo złożone bydle ten outlook i ile wiadomości w sobie gromadzi…) i zastosowanie się do instrukcji

Read more »

Kiedyś, dawno temu, w rodzącym się świecie hip-hopu, powstała kapelka “Nagły Atak Spawacza”. Nie wyróżniałaby się on niczym od innego tego typu chłamu, gdyby nie fakt, że używała ogromnej ilości przekleństw. Przypomniała mi się ona dziś w momencie, gdy dostałem OGROMNĄ ilość spamu, który przyszedł na moje skrzynki pocztowe. Przypomniała mi się dlatego, że nagły przypływ liryzmu spowodował powstanie twórczości na oko nie odróżniającej się procentową zawartością merytoryki od przecinków - zupełnie jak u nich.

A do rzeczy - jak walczyć z <eufemizm>cholernym</eufemizm> spamem obrazkowym^*? Jest kilka wrednych metod - mogę zabronić wklejania obrazków do treści (content filtering) i wymusić przesyłanie ich w załącznikach. Mogę wogóle wymusić zakaz przesyłania obrazków. Tyle, że nie wszystkim korzystającym z danego serwera pocztowego musi się to podobać
Gdybym miał mocny serwer mógłbym robić OCR wstawionym obrazkom (ale w porównaniu do ilości przesyłanej poczty - nie mam).

Czyżby spamerom udało się, (w połączeniu oczywiście z używaniem botnetów, bo inaczej zadziała RBL), znaleźć loophole obecnego systemu zabezpieczeń?

^*niechciana i niezamówiona przesyłka pocztowa zawierająca bezsensowny w całości, ale sensowny w zdaniach tekst i obrazek niosący spamerski przekaz

W ramach walki ze spamem przeszliśmy już przez MUA oraz wstępnie zabezpieczyliśmy MTA. Wstępnie, ponieważ nadal ktoś może podszyć się pod domenę z whitelisty a także nie wszędzie możemy zastosować greylisting. W tej sytuacji wyposażymy naszego postfixa w kolejne narzędzia.

Dwoma chyba najpopularniejszymi pakietami do walki ze spamem oraz wirusami są spamassassin oraz clamav. Ponieważ są to pakiety zewnętrzne, do integracji ich z postfixem użyjemy pośrednika - amavisd-new. Po instalacji odpowiednich pakietów, czyli standardowym aptitude install amavisd-new spamassassin clamav clamav-daemon clamav-freshclam otrzymujemy działające środowisko. Teraz musimy tylko poinstruować amavisa i postfixa jak z niego korzystać.

Read more »

W poprzednim artykule tyczącym się walki ze spamem na stacji klienckiej wspomniałem o konieczności przerzucenia ciężaru filtrowania na serwer. Ten sposób filtrowania ma niestety, jak każdy dobry kij, conajmniej dwa końce. Po pierwsze - musimy zapewnić użytkownikowi możliwość dotarcia do przesyłki, która jednak może spamem nie być (false positives), po drugie wszystkie wiadomości i tak są wrzucane na serwer - czyli mamy zajęte pasmo oraz przestrzeń dyskową.

Metodą, która pozwala obejść te minusy jest graylisting. Działa on w sposób bardzo prosty, wykorzystując sposób działania serwerów SMTP oraz typowe zasady działania spamerów.
Serwery SMTP próbują przesłać wiadomość ‘do skutku’, to znaczy jeśli sesja SMTP nie powiedzie się przy pierwszej próbie, po chwili (równej zazwyczaj długości kolejki i interwałowi jej opróżniania - wiadomość na serwerze wysyłającym przesuwana jest na koniec kolejki przy niemożności dostarczenia), próbują ponownie. Spamerzy zazwyczaj nie wysyłają wiadomości ponownie i ignorują kody błędów. Oznacza to, że jeśli przy pierwszej próbie wysłania nowej wiadomości serwer specjalnie odpowie kodem błędu, to “za chwilę” ta wiadomość jednak do niego dotrze. Jak każda metoda, także ta ma pewne minusy - pierwszym i podstawowym jest zgoda zarządu na jej wprowadzenie - niektóre firmy nie chcą/nie mogą pozwolić sobie na opóźnienia w przyjmowaniu poczty. Ponadto ze względów organizacyjnych wprowadza się często adres publiczny, na który może przychodzić niezamówiona oferta handlowa. Drugim powodem, techcznicznym, jest dodanie kolejnego punktu, gdzie może pojawić się problem w sposobie działania serwera pocztowego. Trzecim, także technicznym problemem są sytuacje, gdy serwer po uzyskaniu kodu 450 zaprzestaje prób i raportuje problem z wysłaniem wiadomości - niestety takie rzeczy także się zdarzają.

Sposobem na zminiminalizowanie opóźnień w kontaktach z partnerami biznesowymi jest stworzenie listy ich domen pocztowych i dodanie ich do białej listy domen, które nie będą poddawane graylistingowi. Oczywiście, jeśli nie jest wprowadzony SPF pozwalający na jako-taką weryfikację adresu nadawcy, to każdy kto wstawi sobie adres domeny z białej listy będzie mógł przesłać spam na nasz serwer pocztowy… Implikuje to niestety także konieczność zastosowania także innych metod walki ze spamem.

To tyle tytułem przydługiego wstępu o samej metodzie, w końcu warto jednak dać odpowiedź na temat - czyli jak dodać graylisting do naszego postfixa? Za przykład posłuży oczywiście mój ulubiony debian i jego pakiet postgrey - o którym warto poczytać na stronie autora. Paczki postgrey są dostępne także dla gentoo, fBSD oraz Fedory.
Jego instalacja jest prosta - komenda aptitude install postgrey spowoduje zainstalowanie dwóch pakietów libberkeleydb-perl oraz postgrey. Automatycznie po instalacji wstaje demon postgrey umiejscawiający się na porcie tcp 60000. Port oraz interfejs (domyślnie localhost) możemy zmodyfikować w /etc/default/postgrey. Możemy tam także zmodyfikować komunikat pojawiający się wraz z błędem 450 - wystarczy do opcji dodać parametr –greylist-text. Najprostsza część instalacji za nami.
Teraz musimy w /etc/postfix/main.cf dodać do smtpd_recipient_restrictions część check_policy_service inet:127.0.0.1:60000. Warto zastanowić się po jakich regułach dodamy tą wartość. U mnie występuje ona po permit_mynetworks, permit_sasl_authenticated co pozwala ominąć greylisting dla wysyłających z moich sieci oraz dla użytkowników zautentykowanych.

Po restarcie postfixa mamy już działający greylisting - jak teraz jednak dopuścić pracę bez graylistingu dla konkretnych domen oraz adresów? Odpowiednie pliki znajdują się w /etc/postgrey - są to odpowiednio whitelist_clients (częściowo zapełniony) oraz whitelist_recipients.

Na koniec ciekawostka - ze względu na te pliki właśnie, postgrey znajduje się także w repozytorium volatile…

Strategii walki ze spamem jest kilka. Pierwsza z nich, to filtry antyspamowe użytkownika zawarte w samym MUA, takie jak filtr bayesowski w thunderbird, czy też aktualizowane co jakiś czas filtry w Oulooku. Plusem tego rozwiązania jest to, że możemy spokojnie przejrzeć wszystkie wiadomości - żadne false positives nie zaszkodzą ciągłości naszego biznesu. Niestety te metody zmuszają nas do ściągnięcia wszystkich wiadomości na stację lokalną, co powoduje czasem spore obciążenie łącza, konieczność składowania tego całego bałaganu gdzieś choćby na chwilę - no i zazwyczaj i tak przejdziemy przez zawartość Junk-mail, chociażby po to, żeby przejrzeć co tam sie znalazło.

Drugim, ciekawszym rozwiązaniem jest zainstalowanie na komputerze pośrednika, swego rodzaju MTA, który będzie filtrował wiadomości przychodzące na naszą pocztę wg zdefiniowanych reguł. Przykładem takiego rozwiązania jest chociażby spampal. Pozwala on na sprawdzenie poczty pod kątem występowania w niej odpowiednich wyrażeń regularnych, dodatkowo ma opcję filtru Bayesa oraz sprawdzenia poczty przychodzącej w bazach RBL.
Ogromnym plusem takiego rozwiązania jest możliwość jego dowolnej konfiguracji, stworzenia białych list poczty a na dodatek uniezależnienie się od mechanizmu antyspamowego samego klienta pocztowego, w szczególności, jeśli na raz używamy kilku (ot chociażby thunderbird, opera, outlook).
Minusów jest także kilka - dużo możliwości konfiguracji to zazwyczaj także pewien problem z poprawnym ustawieniem programu. Są jednak większe problemy - pierwszym z nich jest konieczność współpracy z oprogramowaniem antywirusowym, które ma czasem problem z takim pośredniczącym MTA, co wymusza specyficzną konfigurację oprogramowania klienckiego. Drugim, to problemy z używaniem szyfrowania poczty - w końcu takie MTA to typowy MITM. Nie wspominam już tutaj nawet o exchange czy protokołach innych niż POP3… Widać ewidentnie, że ciężar walki przerzucić trzeba na serwer.

Exchange ma taką dziwną cechę, że bardzo długo się zamyka - szczególnie długo zamyka się Exchange na kotrolerze domeny lub w sytuacji gdy kontroler wolniej komunikuje się z siecią. Wynika to z faktu, że w momencie gdy poczta idzie spać, zaczyna wymieniać mnóstwo informacji z AD. Nie jest to za bardzo skoordynowane, stąd właśnie ten długi czas zamykania serwera. Okazuje się, że można ten czas skrócić poprzez jedną, bardzo prostą komendę:

. Zabicie system attendant service zdecydowanie przyspiesza zamknięcie Exchange.

Czasem może zdarzyć się, że ISP blokuje bezpośredni dostęp do portów 25 w sieciach znajdującej się poza jego domeną. Tak akurat dzieje się w lokalizacji gdzie aktualnie się znajduję, co oznacza, że trzeba własny serwer pocztowy przestawić na inny port. Oczywiście nie można go przestawić całkowicie, ponieważ inne serwery pocztowe nie porozumieją się z nami nie mogąc znaleźć punktu wejścia serwera.

Okazuje się jednak, że konfiguracja postfixa jest przygotowana na taką ewentualność. Jeśli mamy w posfixie uruchomiony mechanizm TLS to spokojnie możemy uruchomić postfixa na porcie 465 (smtps). Wystarczy w pliku /etc/postfix/master.cf odhaszować linijkę:

oraz oczywiście dodać regułkę do firewall’a przepuszczającą ruch na wzmiankowanym porcie
Warto zauważyć, że demon czuwający na porcie 465 nie przedstawia się tak ładnie jak ten porcie 25 - od razu wymaga rozpoczęcia negocjacji TLS.

Osięgniemy w ten sposób dwa cele - pierwszy z nich to możliwość wysyłania poczty, drugi - to pewność bezpiecznego skonfigurowania klientów pocztowych, którym oczywiście nakazujemy łączyć się z portem 465 zamiast 25. Pozostaje jeszcze problem dobrego dopasowania certyfikatów, ale to temat na inny art.

“Ten adres jest zastrzeżony
Ten adres zawiera numer portu sieciowego, który zazwyczaj nie jest wykorzystywany do przeglądania stron www. Firefox anulował żądanie dla bezpieczeństwa użytkownika.”

Firefox, niewiadomo dlaczego ;-), odmawia połączenia z pewnymi portami, na których nie spodziewa się odnaleźć usługi WWW. Niestety, czasem tam naprawdę znajduje się odpowiednia usługa, z której chcemy pobrać dane - np. certyfikaty SSL typu self-signed albo poświadczone przez CA, którego nie ma domyślnie w przeglądarce są do pobrania własnie przez przeglądarkę (dzięki wpisaniu w firefox https://nazwa_serwera:995 dla POP3S, https://nazwa_serwer:993 dla IMAPS czy też https://nazwa_serwera:465 dla Secure SMTP - które to wszystkie serwisy mogą też działać na standardowych portach, co właśnie powoduje problem).
Jak poradzić sobie z tym problemem? Wystarczy dodać w konfiguracji firefox (about:config w pasku adresu) opcję typu ciąg znaków (string) nową opcję network.security.ports.banned.override i wymienić jako wartości listę portów oddzielaną przecinkami. I już działa!

Do obsługi całej masy darmowych kont, które mają swoje różne przeznaczenia, używam Thunderbirda. Przy okazji jednak korzystam z folderu News & Blogs, który jest jak dla mnie wystarczająco dobrym czytnikiem RSS (to znaczy - i tak mam Thunderbirda, więc nie chce mi się instalować nic więcej).

Niestety, po aktualizacji do wersji 1.5.0.4 (najprawdopodbniej) Thunderbird nagle przestał odświeżać mi zawartość kanałów. Nie pomagały restarty, zmiana opcji, włączenie/wyłączenie proxy. Nic. Cóż, chwila googlania i znalazłem odpowiedź w komentarzu. Faktycznie, skasowanie tego pliku (%USERPROFILE%\Dane aplikacji\Thunderbird\Profiles\”profile_name”\Mail\News & Blogs\feeditems.rdf) pozwala na spokojne odtworzenie indexu i dalszą pracę readera. Swoją drogą podobne rozwiązania imały się także Outlook Expressa, gdzie walczyło się z dbxami - oczywiście tylko w poczcie a nie w RSS (:

Będąc w temacie RSS, polecam także dwa dodatki do Firefoxa - pierwszy z nich to RSS Ticker, który tłumaczyłem na polski, pozwalający na dość ciekawe śledzenie feedów, zaś drugi to Wizz RSS Reader, który ujdzie jeśli chodzi o readera wbudowanego w Firefoxa - mnie jednak nie zachwyca.

Jak podaje dziś Rzeczpospolita:

Każdy, kto prowadzi obsługę kont poczty elektronicznej, będzie musiał kupić kasę pancerną i założyć tajną kancelarię, by w niej przechowywać informacje o wysłanych i otrzymanych e-mailach. Taka może być konsekwencja nowelizacji ustawy - Prawo telekomunikacyjne, przygotowanej przez Ministerstwo Transportu i Budownictwa (jeszcze przed podziałem).

Wprowadzenie tej z pozoru drobnej zmiany w prawie spowoduje, że firmy i osoby, które mają serwery pocztowe, będą musiały przechowywać dane o e-mailach przez 24 miesiące. Jeśli rząd i Sejm przystaną na wspieraną przez resorty siłowe koncepcję Ministerstwa Sprawiedliwości, okres ten zostanie wydłużony nawet do pięciu lat. (…)

Dostawca będzie musiał także całą dobę utrzymać w gotowości pracowników z certyfikatami oraz zbudować specjalne systemy bezpiecznego dostępu do danych.

Co to oznacza? Jeśli dobrze rozumiem, to jeśli mała firma wdrożyła sobie Exchange lub bardziej prawdopodbnie SBS, to podpada pod wzmiankowaną ustawę. Jeśli szkoła publiczna mając łącze internetowe postawiła sobie przy okazji serwer z postfixem, choćby jako mail relay, to też będzie nagle musiała budować kancelarię tajną. Jeśli prywatna osoba ma serwer pocztowy w domu na DDNS… także? A postfix służący jako mail relay dla sieci, które korzystają ze smarthostów albo połączeń wdzwanianych?

Uważam, że przeciw takiej nowelizacji ustawy powinna zaprotestować PIIT, ale nie tylko - przede wszystkim sami internauci, którzy nie tylko nagle będą mocniej inwigilowani, (bo i tak są, więc stąd słowo mocniej), ale przede wszystkim poniosą nagle większe koszty korzystania z internetu - bo o ile sama kasa pancerna to tylko parę k złotych, to budowa kancelarii tajnej, wyposażenie conajmniej jednego dostępnego 24/7 (lol) pracownika do jej obsługi wraz z odpowiednim certyfikatem ABW to już kilkanaście ładnych tysięcy.

Jedynym plusem tej ustawy jest wydanie przez firmy pieniędzy na bezpieczeństwo teleinformatyczne - ale chociaż mój portfel także by od tego wzrósł, to wolę, żeby klient pieniądze wydał rozsądniej - świadomie, a nie przez przymus…

To co panie i panowie? Klawiatura w dłoń, baseball do plecaka zamiast laptopa i na ministerstwo! I to w realu a nie wirtualu, żeby kolegom z .gov nie narobić kłopotu

jeden lokalny, nie wadził nikomu, drugi w domenie z exchangem zbratany wiadomości wymieniał w sposób sobie tylko znany…

Tyle poezyji - otóż z różnych względów na jednym komputerze są stworzone dwa profile. Jeden z nich zawiera outlooka z exchangem i konto domenowe, drugi outlooka skonfigurowanego jako klient POP3/IMAP. Chciałbym mieć uruchomione jednocześnie obydwa. Niestety, uruchomienie outlooka z poświadczeniami odpowiedniego konta (usługa “runas”), powoduje, że druga kopia uruchamia się zawsze w kontekście tym samym (bez względu na teoretycznie użyte poświadczenia!)
Jeśli najpierw uruchomię na użytkowniku domenowym - mam outlooka domenowego, jeśli na userze lokalnym lokalnego. W żaden sposób nie udaje mi się mieć dwóch niezależnych kopii…

Czy jest na to jakiś sposób?

Pierwsza część artykułu przeprowadziła nas przez prostą konfigurację postfixa, zapobiegającą przerobieniu naszego serwera na open-relay przy pomocy autoryzacji poprzez pop-before-smtp. Dziś czas na część drugą, czyli jak szybko włączyć autoryzację, tls i mieć to z głowy.

Pierwszą rzeczą jaką trzeba sprawdzić, to czy mamy zainstalowane potrzebne pakiety:

• postfix-tls
• sasl2-bin
• libsasl2
• openssl
• libsasl2-modules

Ruszamy - naszym celem są następujące pliki:

• /etc/postfix/main.cf, czyli plik zawierający opcje postfixa
• /etc/postfix/sasl/smtpd.conf, sposoby autentykacji sasl
• /etc/postfix/smtpd.key, klucz, którym będzie autoryzowany postfix
• /etc/default/saslauthd, konfiguracja demona SASL, który będzie dokonywał autentykacji
• /etc/fstab, nawet tu będziemy musieli dokonać zmiany, jeśli chcemy, żeby sasl działał poprawnie

Na pierwszy ogień idzie konfiguracja postfixa - otwieramy /etc/postfix/main.cf i dodajemy linie:

• smtpd_sasl_auth_enable = yes, odpowiada za włączenie mechanizmu autoryzacji
• broken_sasl_auth_clients = yes, pozwala na autoryzację klientom takim jak OE. Nazwa opcji jest swoją drogą jednoznaczna…
• smtpd_use_tls = yes, pozwalana włączenie szyfrowania transmisji
• smtpd_tls_cert_file = /etc/postfix/smtpd.cert, informuje gdzie znajduje się klucz publiczny serwera
• smtpd_tls_key_file = /etc/postfix/smtpd.key, dla odmiany wskazuje lokalizację klucza prywatnego
• do linijki smtpd_recipient_restrictions = dodajemy opcję permit_sasl_authenticated. Należy ją dodać przed jakimkolwiek zakazem typu reject.

Postfix już skonfigurowany - teraz pozostaje mu tylko dostarczyć dane, które obiecaliśmy. Na pierwszy ogień idzie autentykacja. Przede wszystkim otwieramy plik /etc/default/saslauthd i ustawiamy opcje

(lub “pam” lub “pam shadow”). Szybciutko restartujemy demona (/etc/init.d/saslauthd restart).
Nie jest to wszystko - drugi plik, którym musimy się zająć (a wręcz stworzyć ), to /etc/postfix/sasl/smtpd.conf. Opisuje on jakim mechanizmem posłużymy się do autentykacji - możemy użyć baz danych lub też w opisywanym przypadku, skonfigurowanego przed chwilą demona odwołującego się do kont systemowych. W naszej sytuacji wystarczy do tego pliku dodać linie

W perfekcyjnym świecie to byłoby wszystko, w tym mniej doskonałym okazuje się, że dostaniemy komunikat

Dzieje się tak, ponieważ domyślnie sasl tworzy swój socket w /var/run/saslauthd/ a postfix, działający w chrootowanym środowisku szuka plików w (domyślnie) /var/spool/postfix/var/run/saslauthd/. Tworzenie katalogu (mkdir -p /var/spool/postfix/var/run/saslauthd) a potem tworzenie softlinka (ln -s) jest tu oczywiście opcję, niemniej nie rozwiązującą sytuacji. Dużo lepszym rozwiązaniem (i dość permanentym), jest zamontowanie tego katalogu poprzez dowiązanie. Na stałe rozwiązuje to odpowiednia linijka w /etc/fstab:

.
I już jest prawie dobrze gdyby nie to, że przy próbie autentykacji okazuje się że coś jest nie tak z uprawnieniami (warning: SASL authentication
failure: cannot connect to saslauthd server: Permission denied; warning: SASL authentication
failure: Password verification failed; SASL PLAIN authentication failed). Żeby poprawić sytuację wystarczy dodać postfixa do grupy sasl komendą usermod -G sasl postfix i już po sprawie.

Po restarcie autentykacja już działa. Możemy sprawdzić to telnetując się na port 25. Po komendzie ehlo wyświeli nam się linijka z wspieranymi rodzajami autentykacji. My wydamy następną komendę - AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=. Jeśli mamy użytkownika o loginie test i haśle test to autoryzacja przebiegnie pomyślnie. A tak przy okazji - jeśli nie mamy, to ciąg znaków za metodą PLAIN możemy łatwo uzyskać za pomocą następujące komendy:

jeśli mamy oczywiście zainstalowanego albo perla z modułem MIME::Base64 albo xemacs21-bin

Pozostała nam kwestia bezpieczeństwa. Musimy utworzyć parę kluczy, tak aby można było hasło przesyłać bezpiecznie. W tym zakresie wystarczy wykonać polecenie

. Wpisanie danych daje nam ważny rok, podpisany samemu przez siebie certyfikat. Jeśli mamy certyfikat kwalifikowany, to wystarczy go dograć w to właśnie miejsce.

Voila - cel osiągnięty. Teraz pozostaje dodać spamassassina oraz clamav’a i mamy prosty, funkcjonalny serwer pocztowy, ale o tym w następnych odcinkach.

Debian standardowo jako MTA instaluje Exim’a. Tak samo standardowo natychmiast wymieniam go na postfixa, ze względu na prostotę instalacji oraz konfiguracji tego ostatniego. Faza instalacji przebiega szybciutko, pozostawiając działający serwer SMTP. No - działający o tyle o ile, bo próba wysłania z sieci innej niż wewnętrzne, czy też localhost powoduje błąd bodajże 550, czyli relaying denied.

Admin w takiej sytuacji stoi na rozdrożu - albo otworzyć serwer i dodać się do RBLi jako open-relay, albo wdrożyć jakąś autoryzację. Oczywiście można próbować znaleźć tzw. trzecią drogę, czyli dodawać sieci z których użytkownicy wysyłają pocztę, ale kończy się to na sytuacji, gdy otwiera się na przykład na całą klasę adresową neostrady albo innego chello. Nie na darmo mówili Rzymianie - tertium non datur.

Jeśli chodzi o autoryzację, to najprościej zarówno dla admina jak i użytkowników serwera jest dodać paczkę pop-before-smtp. W zasadzie program prawie nie wymaga konfiguracji (ok, mój przemiły popa3d sprawił tutaj drobne problemy i wymagał ręcznego przeredagowania regexpów), oprócz odhashowania wpisów w /etc/pop-before-smtp/pop-before-smtp.conf dotyczących właściwej identyfikacji faktu autentykacji użytkownika. Sam program działa na zasadzie prostej jak budowa cepa - obserwuje zdefiniowany uprzednio plik, (warto sprawdzić który ma obserwować i to ewentualnie uzupełnic w konfiguracji, np. popa3d wpisuje się domyślnie do daemon.log a ipopd do mail.log), a wypadku zgodności z odpowiednim regexepem dodaje wpis do odpowiedniego pliku (domyślnie /var/lib/pop-before-smtp/hosts). Fakt modyfikacji tegoż pliku wykrywa postfix, któremu w /etc/postfix/main.cf należy do linii mynetworks dodać wpis hash:/var/lib/pop-before-smtp/hosts (o ile zachowaliśmy domyślne ustawienie w zmiennej smtpd_recipient_restrictions i jest tam wartość permit_mynetworks). Wszystko powinno działać, nawet bez zaznaczania magicznej opcji, która pojawiła się w Outlooku 2003 - odbierz pocztę przed wysłaniem. Zazwyczaj użytkownik, w momencie gdy mu się przy pierwszje próbie nie wyśle poczta, wciska ‘Wyślij i odbierz’, no a wtedy wszystkie wpisy sa już aktualne…

No tak, ale porządny admin nie będzie lamerem i nie zostawi tak sprawy. Po co mu dodatkowy soft i to nie zachowujący pełni wygody, skoro użytkownik powinien móc jedynie wysłać pocztę, ze względów chociażby przepustowości łącza w GPRS… (wysyła tylko maila bo ma wordpresa gdzieś, który czyta dość specyficzne maile przechodzące przez rygorystyczną kontrolę… procmaila?). No ale sama autoryzacja to jeszcze nie wszystko, bo latają tacy różni (np. Bigo na MTS2005) z laptopami i nie mając co robić podsłuchują komunikację? Trzeba włączyć także szyfrowanie sesji, żeby nikt użyszkodnikowi hasła nie przechwycił… Ale o tym w częsci drugiej