Wielu z nas marzyło w dzieciństwie, a może nadal marzy, by skonfigurować własny serwer pocztowy. Z marzeniami niestety tak bywa, że jeśli postanowią się już spełnić, to wybiorą do tego najmniej odpowiednią ze wszystkich chwilę. Nie inaczej było w moim przypadku. Sklecony metodami chałupniczymi z części wszelakich serwer po wieloletniej wzorowej służbie odszedł zasłużenie, ale niespodziewanie do komputerowego nieba. Moje dawno nieaktualne już marzenie o konfiguracji serwera pocztowego wydawało się stawać rzeczywistością.

Kiedy wyschły pierwsze łzy na mojej twarzy i minęła pierwsza żałoba, postawiony zostałem przed koniecznością utworzenia w sposób całkowicie błyskawiczny nowej instancji serwera. Z wszystkich usług zależało mi najbardziej na serwisach SMTP oraz POP3. Rozpoczęła się walka z czasem. Miałem zaledwie kilka dni zanim listy już wysłane na adresy w mojej domenie rozpoczną swoją powrotną wędrówkę na adres nadawcy. Przejrzałem posiadany przeze mnie tabor sprzętowy i z przykrością stwierdziłem, że jedyna dostępna w tym momencie maszyna mogąca służyć moim celom to stary, wysłużony i rozpadający się laptop Asusa z Windowsem XP na swoim pokładzie. Jedyne co łączyło go z serwerem z prawdziwego zdarzenia to fakt, że zmieściłby się on w szafie serwerowej. Zresztą jak w każdej innej meblościance ;)

Działajmy!

Potrzebowałem łatwego w konfiguracji, darmowego, możliwego do zainstalowania na Windowsie oraz nie koniecznie naszpikowanego funkcjonalnością rozwiązania. W kontekście serwerów pocztowych obiła mi się o uszy fraza Apache JAMES. Wiedziałem, że jest to projekt napisany w całości w Javie oraz obsługujący protokoły SMTP oraz POP3. Dodatkowo z literki J na początku wnioskowałem, że krzywa nauczania właśnie dla mnie przyjmie wyjątkowo miłe kształty. Postanowiłem więc wypróbować na żywym organizmie wspomniane funkcjonalności agenta oraz zobaczyć co więcej oferuje.

Instalacyjka

Jeśli spodziewacie się wielostronnego, skomplikowanego oraz napisanego ciężkim technicznym językiem opisu instalacji to oczekujcie srogiego zawiedzenia. Przy wybraniu ścieżki dla osób nieprzejawiających skłonności sadomasochistycznych należy ściągnąć jedną z dostępnych binarnych paczek na stronie domowej Apache JAMES oraz rozpakować ją w dowolnie nam pasującym miejscu naszego systemu. W momencie pisania tego artykułu najlepsza wersja szczyciła się numerkiem 2.3.1.

Należy tutaj podkreślić, że JAMES ma budowę modularną pozwalającą na uruchomienie jedynie tych funkcjonalności, które wydają się być dla nas interesujące. Zatem paczka o której mowa zawiera tak naprawdę mikrokontener Avalon Phoenix (na próżno zda się szukanie jakiś o nim informacji w guglach, a przyczyny tego faktu postaram się przybliżyć w dalszej części) wraz z dołączonym Apache JAMESem. Zatem uruchamiać tak naprawdę będziemy mikrokontener, a nie bezpośrednio aplikację serwera pocztowego.

Niesie to za sobą kolejne implikacje. Znajomość Javy nie jest wymagana, a osoby ją znające nie będą w żaden sposób faworyzowane, aż do momentu w którym nie zdecydują się one na własnoręczne rozszerzenie serwera o specyficzne dla swoich potrzeb funkcjonalności. Rozszerzeń tego typu Apache JAMESa można dokonywać poprzez tworzenie tak zwanych mailetów (służy do tego Mailet API), ale ta możliwość nie pozostaje w obszarze zainteresowań tego artykułu.

Mój pierwszy raz

Przed przystąpieniem do konfiguracji aplikację można, a nawet należy uruchomić. Dokonamy tego w zależności od systemu operacyjnego wykonując run.bat lub run.sh. Jak udało mi się sprawdzić aplikacja równie bezproblemowo działa zarówno na Windowsach jak i Linuxach.

Wynikiem pierwszego uruchomienia powinien być log na konsoli podobny do poniżej zaprezentowanego.

Using PHOENIX_HOME:   C:\james-2.3.1
Using PHOENIX_TMPDIR: C:\james-2.3.1\temp
Using JAVA_HOME:      C:\Program Files\Java\jdk1.6.0_03\

Phoenix 4.2

James Mail Server 2.3.1
Remote Manager Service started plain:4555
POP3 Service started plain:110
SMTP Service started plain:25
NNTP Service started plain:119
FetchMail Disabled

W tak zwanym międzyczasie w katalogu apps/james pojawiły się pliki i foldery, które będą nam przydatne podczas konfiguracji serwera.

Konfiguracja

Ktoś kto miał do czynienia w przeszłości z innymi rozwiązaniami pocztowymi takimi jak Sendmail, Exim czy Postfix może powiedzieć, że ich konfiguracja jest prosta jedynie post factum ponieważ przegrzebał się przez tony dokumentacji i ma już to na szczęście za sobą. Będę się starał pokazać, że w przypadku Apache JAMESa jest nieco inaczej.

Nie opiszę tutaj wszystkich możliwych opcji, ale na przykładzie serwera, który miałem okazję konfigurować postaram się pokazać jak osiągnąć:

• serwer SMTP z autentykacji użytkowników
• serwer POP3 z obsługą szyfrowania i autentykacji

Sposób konfiguracji serwera

Do podstawowej konfiguracji serwera będzie nam potrzebny zwykły edytor plików tekstowych. Warto byłoby, aby nie był to jednak Microsoft Notepad, ale program, który w minimalnym choć stopniu wspiera edycję XMLa. Ja osobiście bardziej z przyzwyczajenia niż dlatego, że jest to rzeczywiście najbardziej odpowiednie narzędzie do tego celu wykorzystałem Eclipse‘a.

Aby zmiany, które wprowadzimy do konfiguracji zostały weszły w życie będziemy musieli serwer zatrzymać, a następnie ponownie uruchomić.

Podstawowa konfiguracja

Zlokalizujemy teraz plik konfiguracyjny apps/james/SAR-INF/config.xml. Nie należy się przejmować jego objętością, ponieważ większą jego cześć stanowią komentarze, które powinny nasze zadanie uczynić jeszcze łatwiejszym.

Rozpoczniemy od zmiany podstawowych własności serwera.

<config>
	<James>
		<!-- adres e-mail z którego będą wysyłane (przede wszystkim) informacje o niedostarczonej poczcie -->
		<postmaster>postmaster@bike-diary.org</postmaster>
		<!-- zezwalamy na dostarczanie maili jedynie na explicite wylistowane przez nas serwery -->
		<!-- nie zezwalamy na wysyłanie listów przy użyciu adresów IP -->
		<!-- wszystkie maila wysłane na adresy w domenie bike-diary.org będą traktowane jako maile do lokalnego dostarczenia -->
		<servernames autodetect="false" autodetectIP="false">
			<servername>bike-diary.org</servername>
		</servernames>
		(...)
	</James>
	<spoolmanager>
		<processor name="transport">
			(...)
			<!-- wyłączamy sprawdzanie z jakich adresów IP łączą się nasi użytkownicy -->
			<!-- zamiast tego zastosujemy autentykację SMTP -->
			<!--
				<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor">
				<processor> relay-denied </processor>
				<notice>550 - Requested action not taken: relaying denied</notice>
				</mailet>
			-->
			(...)
			<mailet match="All" class="RemoteDelivery">
				<!-- wymagane przez niektóre serwery SMTP, aby dostarczenie wiadomości mogło się powieść -->
				<mail.smtp.localhost>
					bike-diary.org
				</mail.smtp.localhost>
			</mailet>
		</processor>
	</spoolmanager>
	(...)
	<remotemanager enabled="true">
		(...)
		<!-- przy zdalnej konfiguracji serwera będziemy korzystali z szyfrowania -->
		<useTLS>true</useTLS>
		<handler>
			(...)
			<administrator_accounts>
				<!-- hasło składające się z 8 gwiazdek jest nie do złamania ;) -->
				<account login="root" password="*********" />
			</administrator_accounts>
			(...)
		</handler>
	</remotemanager>
	<pop3server enabled="true">
		<!-- wybieramy port 995, ponieważ będziemy chcieli szyfrować połączenia -->
		<port>995</port>
		<useTLS>true</useTLS>
		(...)
	</pop3server>
	<smtpserver enabled="true">
		(...)
		<handler>
			(...)
			<!-- nie chcemy z naszego serwera zrobić przystani dla spamerów -->
			<authRequired>true</authRequired>
			(...)
		</handler>
	</smtpserver>
	(...)
	<sockets>
		<server-sockets>
			(...)
			<!-- ponieważ chcemy używać szyfrowania musimy odkomentować poniższy fragment -->
			<factory name="ssl"
				class="org.apache.avalon.cornerstone.blocks.sockets.TLSServerSocketFactory">
				<ssl-factory>
					<keystore>
						<file>conf/keystore</file>
						<!-- zmień domyślne hasło -->
						<password>secret</password>
						<!-- zmień domyślne hasło -->
						<key-password>keysecret</key-password>
						<type>JKS</type>
						<protocol>TLS</protocol>
						<algorithm>SunX509</algorithm>
						<authenticate-client>false</authenticate-client>
					</keystore>
				</ssl-factory>
			</factory>
		</server-sockets>
		(...)
	</sockets>
</config>

Powyższy listing przedstawia wprowadzone przeze mnie zmiany do domyślnej konfiguracji serwera wraz z dołączonymi komentarzami wyjaśniającymi powód powstania modyfikacji. Umieszczenie tutaj całej zawartości pliku konfiguracyjnego nie miałoby swojego uzasadnionego sensu, a jedynie znacząco zaciemniłoby prezentowany przeze mnie przykład. Należy jednak zauważyć, że w prawdziwym środowisku produkcyjnym bardziej świadomy swoich potrzeb użytkownik wprowadziłby znacznie większą ilość usprawnień.

Przygotowywanie wsparcia dla szyfrowania

Nim przystąpimy do ponownego uruchomienia serwera konieczne będzie jeszcze wygenerowanie składowiska kluczy (ang. keystore) oraz umieszczenie dostarczonej wraz z Sun JDK paczki dostawców usług kryptograficznych w odpowiedniej lokalizacji.

Dla powyższego przykładu keystore możemy utworzyć przy pomocy dostarczonego wraz z Sun JDK narzędzia keytool.

keytool -genkey -keypass keysecret -keystore keystore -storepass secret

Powyższe polecenie należy wykonać w folderze apps/james/conf. Więcej informacji na temat generowania kluczy można uzyskać tutaj.

Przed przystąpieniem do ponownego uruchomienia serwera musimy jeszcze odnaleźć plik sunjce_provider.jar znajdujący się wewnątrz instalacji Sun JDK. Wspomniany plik należy przekopiować do folderu lib katalogu instalacyjnego Apache JAMESa.

Ponowne uruchomienie serwera

Oczywiście jeżeli mamy otwartą konsole w której jest uruchomiony właśnie serwer aplikacji, to do jego zatrzymania moglibyśmy użyć nieśmiertelnego Ctrl-C ;) My natomiast nauczymy się tą czynność wykonywać w bardziej prawidłowy sposób i przy okazji poznamy kolejny komponent Apache JAMESa, jakim jest RemoteManager.

Wspomniany przed chwilą RemoteManager domyślnie uruchamiany jest na 4555 porcie i komunikuje się ze światem zewnętrznym przy pomocy protokołu telnet. Służy on do ogólnie pojętego zarządzania serwerem pocztowym w tym między innymi pozwala na dodawanie, modyfikowanie oraz usuwanie kont użytkowników.

Z poziomu Windowsa w celach połączenia się z RemoteManagerem możemy wykorzystać PuTTY.

Zalogujmy się zatem wybierając typ połączenia telnet, odpowiedniego hosta oraz port 4555. Naszym oczom powinna ukazać się zachęta do wprowadzenia danych uwierzytelniających (należy zerknąć do pliku konfiguracyjnego w celu upewnienia się jakie dane powinny zostać tutaj wprowadzone). Niestety z przykrością stwierdzam, że wprowadzane przez nas hasło będzie widoczne na ekranie komputera. Należy zatem zachować szczególną ostrożność by krytyczne dane nie zostały przechwycone przez osoby do tego niepowołane. W wyniku udanego logowania oraz wpisania komendy HELP powinniśmy zobaczyć ekran podobny do poniżej zaprezentowanego zawierający wszystkie aktualnie dostępne polecenia obsługi.

Currently implemented commands:
help                                    display this help
listusers                               display existing accounts
countusers                              display the number of existing accounts
adduser [username] [password]           add a new user
verify [username]                       verify if specified user exist
deluser [username]                      delete existing user
setpassword [username] [password]       sets a user's password
setalias [user] [alias]                 locally forwards all email for 'user' to 'alias'
showalias [username]                    shows a user's current email alias
unsetalias [user]                       unsets an alias for 'user'
setforwarding [username] [emailaddress] forwards a user's email to another email address
showforwarding [username]               shows a user's current email forwarding
unsetforwarding [username]              removes a forward
user [repositoryname]                   change to another user repository
shutdown                                kills the current JVM (convenient when James is run as a daemon)
quit                                    close connection

Analizując powyższą listę można w łatwy sposób uzyskać informację na temat dostępnych opcji. Nas w tym momencie będzie interesowała opcja shutdown powodująca grzeczne zakończenie pracy przez serwer. Po udanym zatrzymaniu oraz ponownym uruchomieniu mikrokontenera powinniśmy już na konsoli ujrzeć, że nowe ustawienia weszły w życie (możemy to na przykład sprawdzić weryfikując numery portów na których uruchomiły się poszczególne usługi). Jeżeli coś sugeruje, że serwer nie uruchomił się prawidłowo warto spojrzeć na konsolę oraz zerknąć do folderu z logami apps/james/logs.

Od tej pory po każdorazowej zmianie ustawień serwera polegającej na modyfikacji pliku konfiguracyjnego będziemy musieli wykonać ponowne uruchomienie serwera w sposób jaki został powyżej opisany.

Podstawowe testy usługi

W celu skutecznego przetestowania usług należy przy pomocy RemoteManagera dodać użytkownika testowego (bądź rzeczywsitego). Następnie zgodnie z wprowadzonymi w pliku konfiguracyjnym serwera parametrami można dodać nowe konto pocztowe w swoim ulubionym kliencie poczty. Szczególną uwagę zwrócić należy na ustawienia protokołu SMTP oraz POP3.

Na koniec w ramach przetestowania podstawowej funkcjonalności serwera można wysłać ze swojego innego konta pocztowego na serwerze zewnętrznym wiadomość na testowy adres i vice versa. Jeżeli obie wiadomości zostaną pomyślnie dostarczone będzie to oznaczało, że podstawowa funkcjonalność serwera działa. Hurra!

W przypadku wystąpienia błędów warto przejrzeć pliki logów w poszukiwaniu wartościowych wskazówek oraz sprawdzić ponownie konfigurację serwera.

Czego więcej można się spodziewać?

Przeglądając plik konfiguracyjny można łatwo zorientować się jakie inne nieopisane przeze mnie w tym artykule funkcjonalności posiada Apache JAMES. Za ciekawostkę z pewnością można uznać moduł IMAP (będący w momencie pisanie przeze mnie tego tekstu w fazie eksperymentalnej). Bardziej zainteresowanych czytelników z czystym sumieniem mogę odesłać do oficjalnej dokumentacji Apache JAMESa.

Komu serwer, komu – bo idę do domu.

Literka E w nazwie serwera ma oznaczać, że ma on służyć do rozwiązań biznesowych. Czy rzeczywiście tak jest? Trudno jest mi to jednoznacznie ocenić. Z pewnością sprawdza się wspaniale w zastosowaniach domowych oraz w fazie deweloperskiej rozwoju aplikacji korzystających z serwera pocztowego. Nie lada zaletą jest także jego rozszerzalność, która umożliwia nam w łatwy sposób dodawanie nowych specyficznych funkcjonalności. Zatem każdy musi sobie sam odpowiedzieć, czy Apache JAMES jest rozwiązaniem spełniającym oczekiwania. W moim mniemaniu jest on z pewnością produktem, który zasługuje na swoją szansę.

Wątpliwości architektoniczne

Serwer Apache JAMES jest wciąż mniej lub bardziej dynamicznie rozwijany. Tym bardziej wątpliwości może budzić fakt, że korzysta on z mikrokontenera Apache Avalon, który już dawna temu przestał być wspierany. Na stronie domowej serwera pocztowego można jednak znaleźć informacje, że wspomniane rozwiązanie nie przysparza żadnych większych problemów. Mimo to autorzy planują przenieść swój produkt na inne, wspierane środowisko. Kiedy to będzie miało miejsce? Tego nie wiadomo.

Lineczki

• Strona domowa Apache JAMES
• Generating keys