vermin.eu.org

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:

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:

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