vermin.eu.org

Specjalista IT na tru^Hopie

Entries Comments



Category: poczta


Postfix na szybko, czyli jak wzbogacić swój serwer pocztowy o autoryzację SMTP oraz TLS (część I)

8 January, 2006 (23:05) | debian(ized), linux, poczta | By: vermin

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 :)

zmiana demona pop3 (popa3d na ipopd)

8 January, 2006 (01:30) | debian(ized), linux, poczta | By: vermin

Zanim przejdę do właściwej treści, to chciałbym powitać wszystkich czytelników w Nowym Roku 2006! Pisanie bloga wymaga pracy (co zauważył Michał w komentarzu na R2), na którą w końcówce 2oo5 nie było niestety czasu, a wszelkie idee artykułów, które ulegały odłożeniu, ulegały także zapomnieniu. Czas nadrobić zaległości :)

Przy okazji porządków na serwerze przyszedł czas na standardowe zwiększenie poziomu zabezpieczeń jakiegoś protokołu komunikacyjnego - wybór padł na pop3 i smtp. Chciałem włączyć możliwość szyfrowania komunikacji, a po jakimś czasie wymusić konieczność używania szyfrowania. Wykorzystywanym na serwerze demonem, ze względu na prostotę był popa3d (jedyne opcje konfiguracyjne to czy ma chodzić jako standalone a reszta niestety w źródle, ale za to kompilacja także banalna). Ponieważ jednak ustawienie szyfrowania SSL dla tego demona wymagałoby włączenia stunnel’a, czyli dodatkowej jakby nie było pracy, postanowiłem użyc oprogramowania zawierającego take możliwości w sobie. Ponieważ organicznie nie trawię oprogramowania z pakietu courier, a na serwerze już chodził demon uw-imapd-ssl, do kompletu doinstalowałem ipopd-ssl, który także jest dość, (jak myślałem), banalny. Po szybkiej pracy aptitude po chwili cieszyłem się nowym demonem. No, prawie cieszyłem, ponieważ po wykonaniu komendy telnet server 110 dostałem piękny komunikat Unknown AUTHORIZATION state command. Outlook, (co do którego muszę przygotowywać wszelkie konfiguracje), powiedział to samo. Chwila googlania nie przyniosła rezulatów, więc trzeba było odnieść się do katalogu /usr/share/doc (RTFM!).
I cóż się okazało? Otóż oprogramowanie korzystające z libc-client2002edebian ma standardowo wyłączoną możliwość autoryzacji otwartym tekstem, (od razu przypomniało mi się, że imap też miał jakies problemy, ale jako nowo wdrażana usługa został od razu postawiony w wersji z SSL). Objawia się to tym, że w protokole pop3 wyłączana jest propagacja polecenia user. No i po ptakach. Przecież nie odbiorę w poniedziałek tony telefonów od ludzi, którzy nie moga odebrać poczty inaczej niż przez WWW (na szczęście jakaś furtka im została), i nie powiem im, że trzeba wybrac Menu -> Narzędzia -> Konta blah blah blah zakładka blah checkbox blah zakładka blah OK.
W tej sytuacji należało się zagłębić ciut mocniej i… rozwiązanie mnie rozbawiło. Otóż dokumentacja mówi, że: jest nieoficjalna, jest niewspierana, nikt nie bierze za działanie niczego jakiejkolwiek odpowiedzialności, a pierwsza linia pliku konfiguracyjnego, którego oczywiście nie ma, brzmi: “I accept the risk”. Ostatecznie rozwiązaniem okazało się stworzenie pliku /etc/c-client.cf o brzmieniu:

I accept the risk
set disable-plaintext nil

Voila! Ale i tak przestawienie portu na 995 jest zdecydowanie lepsze :) A zmiana w libc-client przy wymianie wersji może przestac działać…

Ponieważ googlanie mi osobiście nie dało odpowiedzi, zamieszczę ją in English - może komuś się przyda?
Installing (upgrading, etc) package ipopd-ssl/uw-imapd-ssl leaves one without the possibility to authenticate with unencrypted (plain text) password over an insecure connection (except for localhost). To check if this is the problem, one should try to connect over SSL tunnel first (ports 995 for pop3s and 993 for imaps). If this works and normal authorization shows Unknown AUTHORIZATION state command” for pop3 and similar error for imapd, then one need to create file /etc/c-client.cf containing two lines:

I accept the risk
set disable-plaintext nil

Although things should start working now, I strongly advise to switch to secure connection if the server is in the DMZ/internet.