Politechnika Warszawska Rok akademicki Wydziaª Elektroniki i Technik Informacyjnych 2014/2015 Instytut Informatyki
Praca Dyplomowa In»ynierska
Wojciech Szymski
System zarz¡dzania przestrzeni¡ adresów e-mail
Opiekun pracy: prof. nzw. dr hab. in». Piotr Gawrysiak
Ocena pracy: ......
...... Data i podpis Przewodnicz¡cego Komisji Egzaminu Dyplomowego Kierunek: Informatyka Specjalno±¢: In»ynieria Systemów Informatycznych Data urodzenia: 13 wrze±nia 1991 Data rozpocz¦cia studiów: 1 pa¹dziernika 2010
yciorys
Urodziªem si¦ 13 wrze±nia 1991 roku w Warszawie. W latach 2007-2010 ucz¦szczaªem do VIII Liceum Ogólnoksztaªc¡cego im. Wªadysªawa IV w Warszawie. W roku 2010 uko«czyªem szkoª¦ ±redni¡ oraz zdaªem matur¦. W pa¹dzierniku 2010 roku rozpocz¡ªem studia stacjonarne pierwszego stopnia na Wydziale Elektroniki i Technik Informacyjnych na kierunku Informatyka.
...... podpis studenta
Egzamin dyplomowy
Zªo»yª egzamin dyplomowy w dn......
Z wynikiem ......
Ogólny wynik studiów ......
Dodatkowe wnioski i uwagi Komisji ......
......
1 Streszczenie
Przedmiotem pracy byªo zaprojektowanie oraz zaimplementowanie systemu e-mailowego. Przedstawiono dost¦pne na rynku rozwi¡zania oraz wskazano ich zalety i wady. Pozwoliªo to na zde niowanie wymaga« sta- wianych przed systemem. Opisano wykorzystane protokoªy oraz architektur¦ i szczegóªy implementacyjne systemu. Jako efekt pracy powstaª system umo»liwiaj¡cy proste zarz¡dzanie przestrzeni¡ adresów e-mail w obr¦bie wªasnej domeny.
Sªowa kluczowe: e-mail, zarz¡dzanie przestrzeni¡ adresow¡, ltrowanie wia- domo±ci, ochrona przed spamem
E-mail address space management system
The subject of the thesis was to design and create an e-mail system. Review of available solutions was introduced with their pros and cons pointed out. This allowed to de ne the requirements for the system. Used protocols, architecture and implementation details have been described. As a result a system allowing simple management of e-mail address space within an owned domain was created.
Keywords: e-mail, address space management, message ltering, spam pro- tection
2 Pragn¦ serdecznie podzi¦kowa¢ Panu prof. nzw. dr hab. in». Piotrowi Gawrysiakowi za po±wi¦cony czas oraz uwagi, bez których napisanie niniejszej pracy nie byªoby mo»liwe.
Dzi¦kuj¦ rodzicom i siostrze za wsparcie okazane podczas pisania tej pracy. Dzi¦kuj¦ równie» Bartoszowi Szrederowi za okazan¡ cierpliwo±¢ oraz wszystko, czego mnie nauczyª. Spis tre±ci
Wykaz skrótów ...... 6
1. Wprowadzenie ...... 7
1.1. Krótka historia poczty elektronicznej ...... 7 1.2. E-mail we wspóªczesnym ±wiecie ...... 8 1.3. Cel pracy ...... 8 1.4. Struktura pracy ...... 9
2. Model dziaªania poczty elektronicznej ...... 10
2.1. Agenty ...... 10 2.2. SMTP ...... 11 2.3. IMAP ...... 12
3. Przykªady istniej¡cych rozwi¡za« ...... 15
3.1. Gmail ...... 15 3.2. Guerrilla Mail ...... 17 3.3. Post x i Courier IMAP ...... 18 3.4. Podsumowanie ...... 18
4. Koncepcja systemu ...... 20
4.1. MTA ...... 20 4.2. MSA ...... 21 4.3. MDA ...... 21 4.3.1. Potok przetwarzania ...... 21 4.3.2. Grupowanie i zapis ...... 22 4.4. MAA ...... 22 4.5. Przechowalnia ...... 22
5. Implementacja systemu ...... 24
5.1. Go ...... 24 5.2. Kon guracja ...... 24
4 5.3. MTA ...... 25 5.3.1. Authenticator ...... 26 5.3.2. Handler ...... 26 5.4. MSA ...... 26 5.5. MDA ...... 27 5.5.1. Przetwarzanie ...... 27 5.5.2. Utrwalanie ...... 28 5.6. Maildir ...... 28
6. Do±wiadczenia praktyczne ...... 30
6.1. Analiza wydajno±ciowa ...... 33
7. Podsumowanie ...... 35
Bibliogra a ...... 36
A. J¦zyk Go ...... 38
5 Wykaz skrótów
DKIM ang. DomainKeys Identi ed Mail, metoda ª¡czenia domeny z wiado- mo±ci¡ e-mail DNS ang. Domain Name Server, rozproszony system translacji hostów na adresy IP IMAP ang. Internet Message Access Protocol, protokóª synchronizacji skrzy- nek e-mailowych IP ang. Internet Protocol, protokóª komunikacyjny MAA ang. Mail Access Agent, p. 2.1 MDA ang. Mail Delivery Agent, p. 2.1 MRA ang. Mail Retrieval Agent, p. 2.1 MSA ang. Mail Submission Agent, p. 2.1 MTA ang. Mail Transport Agent, p. 2.1 MUA ang. Mail User Agent, p. 2.1 POP3 ang. Post O ce Protocol v3, protokóª odbioru wiadomo±ci e-mail ze zdalnej skrzynki SMTP ang. Simple Mail Transfer Protocol, protokóª przekazywania wiadomo- ±ci e-mail pomi¦dzy MTA SPF ang. Sender Policy Framework, metoda uwierzytelniania serwerów nada- j¡cych wiadomo±ci e-mail TLS ang. Transport Layer Security, protokóª bezpiecznej transmisji danych VPS ang. Virtual Private Server, prywatny serwer wirtualny
6 1. Wprowadzenie
Popularyzacja internetu spowodowaªa, »e tradycyjna komunikacja pocztowa zo- staªa w du»ej cz¦±ci wyparta przez wiadomo±ci elektroniczne. Wynika to z bardzo prozaicznych cech komunikacji internetowej. Transmisja wiadomo±ci przez internet jest o wiele rz¦dów wielko±ci szybsza ni» tradycyjna. Koszt takiej transmisji jest z punktu widzenia u»ytkownika ko«cowego nieistniej¡cy lub pomijalny.
1.1. Krótka historia poczty elektronicznej
Jednym z najstarszych i najpopularniejszych formatów wiadomo±ci elektronicz- nych jest e-mail. Pierwsza koncepcja e-maili jest starsza ni» sieci komputerowe powstaªa w latach 60. XX w. w ±rodowisku akademickim USA. Wiadomo±ci byªy przesyªane w obr¦bie pojedynczej stacji roboczej. Wymiana wiadomo±ci przebie- gaªa w bardzo prosty sposób plik z wiadomo±ci¡ byª kopiowany do folderu od- biorcy. Pierwszymi programami do wysyªania lokalnych e-maili byªy MAILBOX oraz SENDMSG. Rozwi¡zanie to byªo wystarczaj¡ce do momentu powstania ARPA- NET, pierwszej sieci komputerowej. BBN Technologies, rma pracuj¡ca nad ARPA- NET, stworzyªa program CPYNET sªu»¡cy m. in. do zdalnego zapisu plików. Jeden z programistów BBN, Ray Tomlinson, zauwa»yª, »e funkcje programów CPYNET i SENDMSG mo»na poª¡czy¢. Po poª¡czeniu tych programów i stworzeniu systemu adresowania (który funkcjonuje do dzi± w tej samej postaci: u»ytkownik@host), sys- tem do wysyªania wiadomo±ci elektronicznych na odlegªo±¢ byª gotowy. Pierwszy e-mail zostaª wysªany pod koniec 1971 roku. Pomysª okazaª si¦ udany po kilku latach e-maile generowaªy ponad poªow¦ ruchu w ARPANET. W kolejnych latach nast¡piªo wiele zmian w modelu dziaªania poczty elektronicznej. Do dostarczania wiadomo±ci stosowano protokoªy, których oryginalny zamysª u»ycia odbiegaª od wy- syªania e-maili, m. in. FTP i UUCP. W roku 1982 powstaª dedykowany transpor-
7 towi e-maili protokóª SMTP. Obecnie wi¦kszo±¢ globalnej infrastruktury e-mailowej funkcjonuje w oparciu o ten protokóª.
1.2. E-mail we wspóªczesnym ±wiecie
W dzisiejszych czasach posiadanie skrzynki e-mailowej to norma. Podanie ad- resu e-mail jest nieodª¡czn¡ cz¦±ci¡ rejestracji w wi¦kszo±ci serwisów internetowych. Kontakty z tradycyjnymi usªugodawcami (np. bankami) równie» cz¦sto odbywaj¡ si¦ t¡ drog¡. Jest to wygodne rozwi¡zanie, ale posiada swoje wady. Podawanie jednego adresu wszystkim nadawcom cz¦sto prowadzi do napªywu du»ej ilo±ci niezorgani- zowanej poczty. Nie mamy równie» kontroli nad grup¡ osób znaj¡cych dany adres. W przypadku, gdy adres tra w niepowoªane r¦ce mo»e sta¢ si¦ celem spamu. Wady te mo»na w du»ej mierze zneutralizowa¢ stosuj¡c wyra nowane narz¦dzia organi- zacyjne i antyspamowe, ale »aden sko«czony zbiór reguª nie jest w stanie w peªni wyeliminowa¢ wszystkich problemów.
1.3. Cel pracy
Dost¦pne s¡ rozwi¡zania, które staraj¡ si¦ przeciwdziaªa¢ problemom wynikaj¡- cych z natury staªego adresu e-mailowego. Organizacja przychodz¡cej poczty jest sto- sunkowo prostym zadaniem zwykle odbiorca jest w stanie sklasy kowa¢ wiadomo±¢ za pomoc¡ adresu nadawcy lub tematu. Od ltrowywanie niechcianych wiadomo±ci jest du»o trudniejszym zadaniem. Istniej¡ zaawansowane systemy do walki ze spa- mem oparte o bardzo wyra nowane algorytmy. Nadawcy spamu nie pozostaj¡ jednak w tyle stale przystosowuj¡ swoje wiadomo±ci tak, aby ltry miaªy gorsz¡ skutecz- no±¢. Celem pracy jest stworzenie systemu, który poza klasycznymi mechanizmami rozwi¡zywania wcze±niej wspomnianych problemów, u»ywa innego, rzadko stoso- wanego ze wzgl¦dów praktycznych, podej±cia. System opiera si¦ o nieograniczone mo»liwo±ci zarz¡dzania przestrzeni¡ adresów w obr¦bie pojedynczej domeny. Pod- stawowym zaªo»eniem dziaªania jest model, w którym pojedynczy nadawca dostaje unikalny adres, na który wysyªa e-maile. Problem ewentualnej zmiany adresu e-mail zostaje zredukowany do poinformowania o zmianie jednego nadawcy. Dzi¦ki temu jedna z nietypowych operacji, która w klasycznym modelu wydaje si¦ by¢ bardzo
8 radykalna caªkowita rezygnacja z u»ywania danego adresu staje si¦ normalnym przypadkiem u»ycia. Pozwala to m. in. na porzucanie adresów, które tra ªy w r¦ce niepowoªanych osób zajmuj¡cych si¦ reklam¡ specy cznej grupy medykamentów. Kolejn¡ zalet¡ tego modelu jest ªatwo±¢ organizacji przychodz¡cych wiadomo±ci, które mog¡ by¢ klasy kowane na podstawie adresu odbiorcy. Oczywi±cie system ten nie rozwi¡zuje wszystkich problemów zwi¡zanych z poczt¡ elektroniczn¡. Jest jednak dobr¡ podstaw¡, która mo»e by¢ rozszerzana o istniej¡ce ju» klasyczne rozwi¡zania.
1.4. Struktura pracy
Praca ma nast¦puj¡c¡ budow¦: Rozdziaª 2. zawiera opis dziaªania wspóªczesnych systemów e-mailowych. Opi- sany zostaª model transmisji wiadomo±ci pomi¦dzy agentami oraz protokoªy SMTP i IMAP. W rozdziale 3. zaprezentowane zostaªy istniej¡ce systemy e-mailowe. Omówione zostaªy ich mo»liwo±ci oraz zalety i wady. W rozdziale 4. zaprezentowano koncepcj¦ architektury systemu. Rozdziaª 5. zawiera opis implementacji systemu, wraz z uzasadnieniem wyboru u»ywanego j¦zyka i bibliotek. Prezentacja dziaªania aplikacji znajduje si¦ w rozdziale 6. Rozdziaª 7. zawiera podsumowanie oraz dalsze plany rozwoju systemu. W dodatku A przedstawiona zostaªa charakterystyka j¦zyka Go. 2. Model dziaªania poczty elektronicznej
2.1. Agenty
Architektura obecnych systemów e-mailowych opiera si¦ o koncepcj¦ zró»nico- wanych agentów. Ró»ne agenty odpowiadaj¡ za poszczególne etapy dostarczania wiadomo±ci pomi¦dzy nadawc¡ i odbiorc¡. We wspóªczesnym modelu wyró»nia si¦ sze±¢ rodzajów agentów[5]: MUA oprogramowanie klienckie. Odpowiada za prezentacj¦ e-maili i komu- nikacj¦ z agentami zewn¦trznymi, tj. najcz¦±ciej MSA i MAA. Przykªadem takiego oprogramowania jest np. Thunderbird i MS Outlook. MTA odpowiada za transport e-maili w sieci. W przypadku, gdy adres do- celowy e-maila znajduje si¦ w znanym miejscu (najcz¦±ciej komputer lokalny lub w sieci lokalnej), przekazuje go do MDA, w innym przypadku przekazuje go do MTA pod adresem, znajduj¡cym si¦ w DNS-owym rekordzie MX hosta docelowego. Komunikuje si¦ z innymi MTA za pomoc¡ protokoªu SMTP. MSA punkt wej±ciowy e-maili do sieci. Odbiera wiadomo±¢ wychodz¡c¡ od MUA i przekazuje do znanego sobie MTA. Bardzo cz¦sto MSA s¡ jedynie warstw¡ abstrakcji naªo»on¡ na dziaªaj¡cy pod spodem MTA. MDA odpowiada za zapisanie e-maila w lokalnej przechowalni adekwatnej dla odbiorcy wiadomo±ci. Agent ten mo»e wykonywa¢ równie» wst¦pne przetwarza- nie, np. odsiewanie wiadomo±ci zawieraj¡cych spam lub zªo±liwe oprogramowa- nie. MAA odpowiada za udost¦pnienie e-maili zapisanych w przechowalni. Zwykle komunikuje si¦ z MUA poprzez protokoªy IMAP i POP3. MRA jest to agent pobieraj¡cy e-maile od MAA. Charakter dalszych dziaªa« zale»y od agenta. Mo»e to by¢ zarówno zapis lokalny, jak i ponowne wstrzykni¦cie wiadomo±ci do sieci.
10 2.2. SMTP
Protokóª SMTP sªu»y do przekazywania wiadomo±ci e-mail w sieci. Jest to protokóª tekstowy, oparty o ograniczony zbiór polece«. Podstawowa wersja protokoªu SMTP de niuje nast¦puj¡ce polecenia: HELO hostname Rozpoczyna sesj¦ SMTP. hostname host, którym przedstawia si¦ klient EHLO hostname Rozpoczyna sesj¦ SMTP. W odpowiedzi serwer wysyªa list¦ dost¦pnych polece«. hostname host, którym przedstawia si¦ klient MAIL FROM:
11 Istniej¡ równie» rozszerzenia protokoªu opisane w uzupeªniaj¡cych dokumentach RFC[2][3]. Przykªadowe polecenia, które s¡ cz¦sto stosowane to: STARTTLS Rozpoczyna negocjacj¦ sesji TLS. AUTH
2.3. IMAP
Protokóª IMAP sªu»y do pobierania wiadomo±ci ze zdalnego serwera oraz zarz¡dzania tymi wiadomo±ciami. Podobnie jak SMTP jest to protokóª tekstowy. Poni»ej przedstawiony zostaª wybrany zbiór polece«.
Polecenia dost¦pne w ka»dym stanie: CAPABILITY Zwraca list¦ mechanizmów uwierzytelniaj¡cych i rozszerze« protokoªu dost¦p- nych na serwerze. NOOP Operacja pusta. LOGOUT Ko«czy sesj¦ i zamyka poª¡czenie.
Polecenia dost¦pne w stanie nieuwierzytelnionym (Not Authenticated): LOGIN Jako parametry przyjmuje login i hasªo. W przypadku sukcesu przechodzi do stanu Authenticated. STARTTLS Rozpoczyna negocjacj¦ sesji TLS.
12 Polecenia dost¦pne w stanie uwierzytelnionym (Authenticated) i w stanie wybranej skrzynki (Selected): SELECT Wybiera podan¡ skrzynk¦ do dalszych dziaªa«. Przechodzi do stanu Selected. EXAMINE Dziaªa jak SELECT, ale wybiera skrzynk¦ w trybie tylko do odczytu. CREATE Tworzy skrzynk¦ o podanej nazwie. DELETE Usuwa skrzynk¦ o podanej nazwie. RENAME Zmienia nazw¦ podanej skrzynki. SUBSCRIBE Ustawia podan¡ skrzynk¦ jako aktywn¡. UNSUBSCRIBE Ustawia podan¡ skrzynk¦ jako nieaktywn¡. LIST Jako parametr przyjmuje nazw¦ referencyjn¡. Zwraca list¦ pasuj¡cych skrzynek. LSUB Dziaªa jak LIST, ale zwraca tylko aktywne skrzynki. STATUS Zwraca status podanej skrzynki (m. in. liczb¦ wiadomo±ci). APPEND Jako parametry przyjmuje nazw¦ skrzynki i wiadomo±¢. Dodaje wiadomo±¢ do skrzynki.
Polecenia dziaªaj¡ce wyª¡cznie w stanie Selected: CHECK Zwraca informacj¦ o wewn¦trznym stanie wybranej skrzynki na serwerze. Serwer mo»e potraktowa¢ t¦ komend¦ jako NOOP. CLOSE
13 Zamyka skrzynk¦, powraca do stanu Selected oraz kasuje wszystkie wiadomo±ci z ag¡ \Deleted. EXPUNGE Usuwa wszystkie wiadomo±ci z ag¡ \Deleted z wybranej skrzynki i zwraca list¦ ich identy katorów. SEARCH Zwraca list¦ wiadomo±ci pasuj¡cych do warunków zapytania. FETCH Zwraca wybrane wiadomo±ci lub ich fragmenty. STORE Mody kuje agi wybranych wiadomo±ci. COPY Kopiuje wybran¡ wiadomo±¢ do podanej skrzynki. UID Jako argument przyjmuje komendy COPY, FETCH, STORE lub SEARCH, ale jako ich argumenty lub wyniki podawane s¡ unikalne identy katory wiado- mo±ci. 3. Przykªady istniej¡cych rozwi¡za«
3.1. Gmail
Gmail jest to bezpªatny serwis poczty elektronicznej stworzony przez rm¦ Go- ogle. W ramach osobistego konta udost¦pniana jest skrzynka e-mailowa, do której dost¦p mo»na uzyska¢ poprzez stron¦ WWW1 lub z poziomu innego klienta, komu- nikuj¡cego si¦ z Gmailem za pomoc¡ SMTP i IMAP. Interfejs serwisu jest wysoce intuicyjny. Jako widok gªówny u»ytkownikowi pre- zentowana jest skrzynka Odebrane. Odczytanie wiadomo±ci ogranicza si¦ do wy- boru jej tematu oraz wycinka tre±ci z listy.
Rysunek 3.1. Widok gªówny przegl¡darkowego interfejsu serwisu Gmail
Interfejs przegl¡darkowy Gmaila dokonuje równie» organizacji poczty w w¡tki. Odpowiedzi na wiadomo±¢ pierwotn¡ grupowane s¡ wraz z ni¡. W tym celu u»ywa nagªówków Message-ID oraz In-Reply-To.
1 https://www.gmail.com
15 Rysunek 3.2. Widok w¡tku wiadomo±ci serwisu Gmail
Zalet¡ serwisu jest równie» udost¦pnienie u»ytkownikowi nieograniczonego podzbioru przestrzeni adresów e-mail. Do u»ytkownika [email protected] kierowane s¡ równie» wszystkie wiadomo±ci adresowane na adresy postaci [email protected]. Umo»liwia to tworzenie ltrów, które wspomagaj¡ orga- nizacj¦ wiadomo±ci.
Rysunek 3.3. Tworzenie ltru dla su ksu +shyym.com
16 Tak ograniczona przestrze« adresowa posiada jednak nieodª¡czn¡ wad¦. Uzyska- nie adresu pierwotnego na podstawie aliasu ogranicza si¦ do wyci¦cia w nim symboli od znaku + do znaku @ (wª¡czaj¡c +). System nie pozwala zatem na pewn¡ identy kacj¦ nadawcy opieraj¡c si¦ wyª¡cznie o adres odbioru.
3.2. Guerrilla Mail
Serwis Guerrilla Mail2 oferuje jednorazowe, tymczasowe skrzynki odbiorcze. Wchodz¡c na stron¦ u»ytkownik dostaje od serwisu zestaw adresów e-mail, które tra aj¡ do skrzynki dost¦pnej z poziomu strony.
Rysunek 3.4. Interfejs serwisu Guerrilla Mail
Gªównym przypadkiem u»ycia serwisu jest jednorazowe odebranie wiadomo±ci z danego serwisu. Przykªadem takich wiadomo±ci s¡ np. potwierdzenia rejestra- cji w serwisach, zawieraj¡ce link aktywacyjny. W momencie opuszczenia strony skrzynka przestaje funkcjonowa¢ i wszystkie wiadomo±ci przychodz¡ce s¡ ignoro- wane. Serwis oferuje równie» mo»liwo±¢ ponownego u»ycia skrzynki. Ka»dy zestaw ad- resów przypisany jest do konkretnego identy katora. W momencie ustawienia iden- ty katora na poprzednio u»ywany, zestaw adresów zostaje ponownie udost¦pniony u»ytkownikowi. Rozwi¡zanie to mo»e posªu»y¢ np. do resetowania hasªa w serwisie,
2 https://www.guerrillamail.com/
17 któremu u»ytkownik podaª tymczasowy e-mail. Jest ono jednak obarczone niebez- piecze«stwem przechwycenia skrzynki przez osob¦ trzeci¡.
3.3. Post x i Courier IMAP
Popularnym rozwi¡zaniem u»ywanym przez u»ytkowników posiadaj¡cych wªasne serwery jest u»ycie systemów Post x i Courier IMAP. System Post x3 jest zaawansowanym MTA posiada wiele funkcji[9], takich jak: kontrola spamu realizowana poprzez wiele kon gurowalnych moduªów, m. in. listy dost¦pu, ograniczanie cz¦stotliwo±ci napªywu (ang. rate limiting), ltry za- warto±ci, kontrola SPF i DKIM; szeroki zakres obsªugiwanych rozszerze« SMTP, np. STARTTLS, 8BIT- MIME, rozszerzone kody stanu; obsªuga wielu baz danych, np. MySQL, PostgreSQL, LDAP, Berkeley DB, SQLite, Memcache, LMDB. Posiada równie» wbudowany moduª MDA. Obsªuguje on przechowalnie w for- matach mbox oraz Maildir. Post x pozwala u»ytkownikowi na zde niowanie skrzynek odbiorczych dost¦p- nych pod okre±lonymi adresami. Pozwala równie» tworzy¢ aliasy, które przekierowuj¡ wiadomo±ci na inne adresy. Nie udost¦pnia jednak mo»liwo±ci kierowania wiadomo±ci do specy cznego miejsca w przechowalni. Do odczytu wiadomo±ci z przechowalni w formacie Maildir posªu»y¢ mo»e pro- gram Courier IMAP4. Udost¦pnia on zintegrowane serwery POP3 i IMAP oraz interfejs WWW do zarz¡dzania skrzynk¡.
3.4. Podsumowanie
Zaprezentowane w tym rozdziale systemy zostaªy wybrane, jako reprezentanci pewnych kategorii. Gmail oferuje skrzynki ogólnego u»ytku, Guerrilla Mail sªu»y jako skrzynka tymczasowa, a Post x i Courier IMAP s¡ wysoko kon gurowalnymi
3 http://www.postfix.org 4 http://www.courier-mta.org/imap/
18 systemami dla posiadaczy wªasnych serwerów. Ka»de z tych rozwi¡za« posiada swoje zalety i wady. Analiza cech charakterystycznych danych systemów wykazaªa, »e sprawdzaj¡ si¦ one ±wietnie w swoich kategoriach. Przegl¡daj¡c wymienione systemy mo»na odnie±¢ wra»enie, »e obecnie istniej¡ce rozwi¡zania s¡ w peªni wystarczaj¡ce. Zwrócono jednak uwag¦ na ograniczenia tych systemów. aden z analizowanych systemów nie zapewnia jednocze±nie niezwi¡za- nych ze sob¡ adresów prowadz¡cych do jednej skrzynki, staªej przechowalni oraz prostoty kon guracji. 4. Koncepcja systemu
Gªównym zaªo»eniem pracy jest dostarczenie w peªni funkcjonalnego systemu e-mailowego. Typowy u»ytkownik posiada na komputerze lokalnym wybrane przez siebie MUA i oczekuje, »e b¦dzie ono wspóªpracowa¢ z oprogramowaniem po stronie serwera w standardowy sposób. To samo dotyczy poczty przychodz¡cej oprogra- mowanie staraj¡ce si¦ dostarczy¢ wiadomo±¢ do opisywanego systemu u»ywa ±ci±le okre±lonego sposobu. W celu zapewnienia kompatybilno±ci z powszechnie u»ywa- nymi programami, system udost¦pnia nast¦puj¡ce punkty ko«cowe (ang. endpoint): MTA pod portem 25 MTA pod portem 587 (z wymuszonym TLS) MAA pod portem 143
Rysunek 4.1. Ogólny schemat systemu
4.1. MTA
Moduª MTA dziaªa pod standardowymi portami 25 oraz 587. Usªuga na porcie 587 wymusza szyfrowanie transmisji, natomiast szyfrowanie na porcie 25 jest opcjo- nalne. MTA dziaªa w oparciu o protokóª SMTP. Udost¦pnia równie» rozszerzenia
20 tego protokoªu: AUTH oraz STARTTLS. Po otrzymaniu wiadomo±ci, MTA po- dejmuje dalsze dziaªania na podstawie hostów adresów docelowych. W przypadku, gdy hostem docelowym jest system lokalny, wiadomo±¢ przekazywana jest do moduªu MDA. Pozostaªe przypadki traktowane s¡ jako u»ycie lokalnego MTA jako MSA.
4.2. MSA
Moduª MSA jest w opisywanym systemie integraln¡ cz¦±ci¡ MTA, ale na- rzuca dodatkowe wymagania dotycz¡ce bezpiecze«stwa. Przede wszystkim wiado- mo±¢ nadana z danego systemu traktowana jest w pewnym sensie jako po±wiadczona przez ten system. Nie jest to w »adnym sensie podpis elektroniczny. Po±wiadczenie wynika z faktu, »e nadanie wiadomo±ci przez protokóª SMTP wymaga zestawienia poª¡czenia TCP. Adres IP serwera nadaj¡cego nie mo»e by¢ w tym przypadku sfaªszowany. Du»a cz¦±¢ systemów odbieraj¡cych sprawdza, czy host podany w polu nadawcy jest zgodny z adresem IP systemu nadaj¡cego. Z tego powodu nale»y za- bezpieczy¢ mo»liwo±¢ nadawania wiadomo±ci z opisywanego systemu. Jest to zre- alizowane za pomoc¡ uwierzytelnienia za pomoc¡ loginu i hasªa. Kredencjaªy s¡ danymi o szczególnie du»ej warto±ci i w zwi¡zku z tym u»ycie MSA wymaga równie» szyfrowania poª¡czenia.
4.3. MDA
Moduª MDA posiada dwa gªówne zadania. Zadaniem pierwszym jest przetwo- rzenie wiadomo±ci oraz, w przypadku gdy wiadomo±¢ jest niepo»¡dana, odrzucenie jej. Nast¦pnie, je»eli wiadomo±¢ pomy±lnie przeszªa wst¦pn¡ ocen¦, MDA zapisuje j¡ w odpowiednim miejscu przechowalni.
4.3.1. Potok przetwarzania
System nie posiada wbudowanych metod wst¦pnego przetwarzania wiadomo±ci przychodz¡cych. Udost¦pnia jednak kon gurowalny potok zewn¦trznych polece«, które mog¡ w dowolny sposób wpªywa¢ na plik z odebran¡ wiadomo±ci¡. W szcze- gólno±ci zamiana pliku z wiadomo±ci¡ na plik pusty traktowana jest jako odrzucenie
21 wiadomo±ci. Poszczególne skªadowe potoku podawane s¡ jako ±cie»ki do plików wy- konywalnych operuj¡cych na pliku e-mail.
4.3.2. Grupowanie i zapis
Jedn¡ z podstawowych zakªadanych funkcjonalno±ci systemu jest grupowanie wiadomo±ci na podstawie zycznego nadawcy. Z punktu widzenia MUA, wiadomo- ±ci od unikalnych nadawców przechowywane s¡ w oddzielnych katalogach. Z zaªo»e« u»ytkowych wynika, »e adres odbiorcy jest ±ci±le zwi¡zany z zycznym nadawc¡. W zwi¡zku z tym moduª MDA mo»e grupowa¢ wiadomo±ci na podstawie adresu odbiorcy. Na podstawie kon guracji u»ytkownika dla ka»dej wiadomo±ci wyznaczany jest katalog docelowy. Zapis wiadomo±ci w podanym katalogu realizowany jest za pomoc¡ moduªu przechowalni.
4.4. MAA
Zadaniem MAA jest po±redniczenie w komunikacji mi¦dzy MUA i przecho- walni¡. Komunikacja pomi¦dzy MUA i MAA odbywa si¦ za pomoc¡ protokoªu IMAP.
4.5. Przechowalnia
Moduª przechowuj¡cy wiadomo±ci powinien umo»liwia¢ hierarchiczn¡ repre- zentacj¦ wiadomo±ci, obsªug¦ oznacze« protokoªu IMAP oraz by¢ bezpieczny w ±rodowisku wielow¡tkowym. Istniej¡ gotowe koncepcje tego typu przechowalni, m. in. Maildir oraz Maildir++. Autor zdecydowaª si¦ na implementacj¦ skrzynki w formacie Maildir++, która speªnia wy»ej wymienione kryteria[12].
Przechowalnia udost¦pnia nast¦puj¡ce metody: odczyt hierarchii katalogów stworzenie katalogu w danym miejscu hierarchii usuni¦cie katalogu zmiana nazwy katalogu odczyt wiadomo±ci
22 stworzenie wiadomo±ci w danym miejscu hierarchii usuni¦cie wiadomo±ci przesuni¦cie wiadomo±ci do innego katalogu zmiana atrybutów IMAP wiadomo±ci 5. Implementacja systemu
Przedstawiona w rozdziale 3 analiza dost¦pnych na rynku systemów e-mailowych wykazaªa, »e opracowana funkcjonalno±¢ nie jest w prosty sposób osi¡galna przy ich u»yciu. Narodziªo to konieczno±¢ zaimplementowania autorskiego systemu, który speªnia oczekiwane zaªo»enia. Poni»sza praca zawiera projekt oraz implementacj¦ tego systemu. W rozdziale 4 przedstawiona zostaªa ogólna architektura systemu. Jest to opis funkcjonalno±ci oraz zale»no±ci poszczególnych komponentów tego systemu. W roz- dziale 5 znajduje si¦ opis implementacji poszczególnych komponentów oraz ich po- ª¡cze« w spójny system.
5.1. Go
Opisywany system zostaª zaimplementowany przy u»yciu j¦zyka Go1. Jest to otwarty j¦zyk wysokiego poziomu stworzony przez rm¦ Google. Gªównymi zaletami Go s¡ prostota u»ycia, czysto±¢ kodu, wysoka wydajno±¢ stworzonych aplikacji oraz szybko±¢ kompilacji kodu. J¦zyk posiada rozwini¦t¡ bibliotek¦ standardow¡ oraz roz- budowane konstrukcje synchronizacyjne. Jednym z najpopularniejszych zastosowa« Go jest pisanie serwerów sieciowych. Szerszy opis j¦zyka wraz z przykªadami u»ycia znajduje si¦ w dodatku A.
5.2. Kon guracja
Kon guracja moduªów domy±lnie przechowywana jest w bazie danych SQLite. Wybór SQLite podyktowany byª ograniczaniem zewn¦trznych zale»no±ci systemu. Opisywany system zawiera wbudowany sterownik go-sqlite32. System mo»e by¢
1 http://www.golang.org 2 https://github.com/mattn/go-sqlite3
24 w sposób przezroczysty dla moduªów zale»nych rozszerzony o mo»liwo±¢ korzystania z innych baz danych. Warstwa dost¦pu do bazy danych zrealizowana zostaªa za pomoc¡ biblioteki sqlx3. Baza jest wersjonowana program sprawdza na pocz¡tek zgodno±¢ schematu bazy z oczekiwaniami. System nie gwarantuje obsªugi ka»dej wersji schematu bazy. Przy zapewnieniu wyª¡czno±ci dost¦pu programu do bazy, moduª kon guracji zapewnia równie» mo»liwo±¢ obserwowania zmian kon guracji przez moduªy zale»ne. Dzi¦ki temu moduªy z mo»liwo±ci¡ przeªadowania w locie mog¡ by¢ informowane o takiej potrzebie. Pozwala to na przetrzymywanie kon guracji w pami¦ci programu.
5.3. MTA
Zadaniem moduªu MTA jest odebranie przychodz¡cego poª¡czenia SMTP. Re- alizacja obsªugi protokoªu SMTP jest realizowana za pomoc¡ biblioteki smtpd4. Biblioteka udost¦pnia mo»liwo±¢ dowi¡zania wªasnych procedur obsªugi (ang. han- dler) poszczególnych etapów poª¡czenia SMTP. Biblioteka udost¦pnia nast¦puj¡ce handlery: Handler(peer, envelope) wywoªywany po odebraniu wiadomo±ci peer parametry poª¡czenia envelope nagªówki i tre±¢ wiadomo±ci ConnectionChecker(peer) wywoªywany przy nowym poª¡czeniu przychodz¡cym peer parametry poª¡czenia HeloChecker(peer, name) wywoªywany po komendzie HELO lub EHLO peer parametry poª¡czenia name nazwa hosta, którym przedstawiªa si¦ druga strona SenderChecker(peer, addr) wywoªywany po komendzie MAIL FROM
3 https://github.com/jmoiron/sqlx 4 https://bitbucket.org/chrj/smtpd
25 peer parametry poª¡czenia addr podany przez drug¡ stron¦ adres nadawcy RecipientChecker(peer, addr) wywoªywany po komendzie RCPT TO peer parametry poª¡czenia addr podany przez drug¡ stron¦ adres odbiorcy Authenticator(peer, username, password) wywoªywany po komendzie AUTH peer parametry poª¡czenia username podana przez drug¡ stron¦ nazwa u»ytkownika password podane przez drug¡ stron¦ hasªo Opisywany system implementuje handlery Handler i Authenticator opisane w ko- lejnych sekcjach.
5.3.1. Authenticator
Handler Authenticator wery kuje zgodno±¢ kredencjaªów podanych przez drug¡ stron¦ poª¡czenia z kredencjaªami zapisanymi w kon guracji. W przypadku sukcesu, argument peer kolejnych handlerów jest uzupeªniony o te kredencjaªy.
5.3.2. Handler
Handler jest dyspozytorem (ang. dispatcher) wiadomo±ci dziaªaj¡cym na pod- stawie adresów odbiorców. Lista odbiorców dzielona jest na odbiorców lokalnych i zewn¦trznych. Wiadomo±¢ wraz list¡ odbiorców lokalnych przekazywana jest dalej do moduªu MDA. Je»eli poª¡czenie jest uwierzytelnione kredencjaªami u»ytkownika systemu oraz lista zawiera odbiorców zewn¦trznych, wiadomo±¢ jest przekazywana do moduªu MSA.
5.4. MSA
Zadaniem moduªu MSA jest dostarczenie wiadomo±ci wychodz¡cej do zde nio- wanej listy odbiorców. Udost¦pnia nast¦puj¡c¡ metod¦: Send(from, to, msg) przyjmuje wiadomo±¢ do wysªania
26 from adres nadawcy to lista adresów odbiorców msg payload W celu nadania moduª dzieli list¦ odbiorców na podstawie hostów, a nast¦pnie dla ka»dego hosta wyznacza adres serwera docelowego. Adres docelowego MTA dla danego hosta jest wyznaczany na podstawie wpisów DNS MX dla tego hosta. Je±li takie wpisy nie istniej¡, zakªada si¦, »e wiadomo±¢ nale»y dostarczy¢ bezpo±red- nio do hosta docelowego. Po wyznaczeniu serwerów docelowych, MSA ª¡czy si¦ z wyznaczonymi MTA i dostarcza im wiadomo±¢, podaj¡c w komendach RCPT TO wszystkie adresy e-mail, które odpowiadaªy danemu MTA. Nagªówki To i CC wiadomo±ci, znajduj¡cy si¦ w payloadzie, pozostaj¡ niezmody kowane (tj. nie s¡ z nich usuwane informacje o odbiorcach na innych serwerach).
5.5. MDA
Moduª MDA zajmuje si¦ przetwarzaniem odebranych wiadomo±ci oraz ich utrwaleniem. Udost¦pnia nast¦puj¡c¡ metod¦, która wykonuje te czynno±ci: Store(from, to, msg, peer) przyjmuje wiadomo±¢ do obróbki i zapisu from adres nadawcy to lista adresów odbiorców msg payload peer informacje o serwerze nadawcy
5.5.1. Przetwarzanie
Przetwarzanie wiadomo±ci obejmuje wery kacj¦ poprawno±ci payloadu, uzupeª- nienie odpowiednich nagªówków oraz obróbk¦ przez zde niowany przez u»ytkow- nika potok. Obróbk¦ potokow¡ realizuje moduª podrz¦dny. Tworzy on tymczasowy plik zawieraj¡cy payload, nast¦pnie wywoªuje na nim kolejne polecenia zde niowane w kon guracji. Polecenia w potoku dostaj¡ jeden argument ±cie»k¦ do pliku z pay- loadem. Oczekiwanym rezultatem jest mody kacja tego pliku w miejscu. W zwi¡zku z tym niektóre z programów wymagaj¡ opakowania ich w skrypt powªoki, który za-
27 pewni kompatybilno±¢ z opisywanym moduªem. Poni»ej przedstawiony zostaª przy- kªadowy skrypt opakowuj¡cy.
Wydruk 5.1. Skrypt opakowuj¡cy do programu SpamAssassin #!/bin/bash spamassassin −Le "$1" i f [ $? −gt 0 ] ; then echo "" > "$1" f i
Je±li jeden z programów potoku wyczy±ci plik, wiadomo±¢ zostanie potraktowana jako odrzucona. W innym przypadku moduª zwróci odpowiednio zmody kowany payload.
5.5.2. Utrwalanie
Podstawowym zadaniem moduªu MDA jest utrwalanie wiadomo±ci. Implemen- tacja moduªu pozwala na dwa rodzaje utrwalenia: zapis w skrzynce o formacie Ma- ildir++ oraz przekierowanie na inny adres. Po przetworzeniu wiadomo±ci moduª przetwarza list¦ odbiorców. Sprawdzana jest zgodno±¢ tych adresów z hostem lokalnym. Nast¦pnym krokiem dla ka»dego adresu jest jego odwzorowanie na miejsce zapisu w skrzynce lub adres przekierowania. Po stworzeniu list docelowych nast¦puje zapis lokalny oraz przekierowanie wiadomo- ±ci. Przekierowanie realizowane jest przez moduª MSA. Zapis lokalny odbywa si¦ poprzez wykonanie metody Save moduªu Maildir.
5.6. Maildir
Moduª Maildir jest implementacj¡ standardu przechowalni wiadomo±ci Mail- dir++. Z powodu mo»liwo±ci równoczesnego dost¦pu do zmiennych danych, zawiera on dwustopniow¡ synchronizacj¦. Pierwszym etapem synchronizacji jest synchro- nizacja na poziomie programu. Jest ona zaimplementowana poprzez paradygmat j¦zyka Go: wspóªdzielenie przez komunikacj¦. Paradygmat ten polega na blokowa- niu praw dost¦pu do obiektu poprzez w¡tkowo-bezpieczne kanaªy. Szczegóªowy opis tego mechanizmu zawarty jest w dodatku A. Drugim etapem synchronizacji jest synchronizacja na poziomie systemu plików. Pliki, których tre±¢ mo»e si¦ zmienia¢,
28 tj. wiadomo±ci w trakcie zapisu, tworzone s¡ w katalogu tmp. Zgodnie ze specy- kacj¡ wyª¡czny dost¦p do tych plików ma ich proces tworz¡cy. Po ostatecznym zapisie plik z wiadomo±ci¡ przenoszony jest do katalogu cur, gdzie dost¦p do niego mog¡ uzyska¢ równie» zewn¦trzne procesy (np. lokalne MUA). Dziaªania na plikach w katalogu cur musz¡ by¢ atomowe. Nazwy plików tworzonych przez moduª maj¡ nast¦puj¡ce wªa±ciwo±ci: s¡ unikalne (tworzone s¡ na podstawie wielu pseudolosowych zmiennych) zawieraj¡ metadane IMAP zawieraj¡ informacje o miejscu w hierarchii katalogów IMAP Moduª udost¦pnia metody, które dziaªaniem przypominaj¡ operacje na systemie plików. Szczegóªy dotycz¡ce nazewnictwa nie s¡ udost¦pniane na zewn¡trz. 6. Do±wiadczenia praktyczne
Do±wiadczenia przeprowadzone zostaªy za pomoc¡ programu Swaks1. Program ten pozwala na proste wysyªanie wiadomo±ci testowych z kon gurowalnymi para- metrami. Serwer do±wiadczalny pracowaª z nast¦puj¡c¡ kon guracj¡: Host wªasny: shyym.com Port SMTP #1: 25 Port SMTP #2: 587 (wymuszony STARTTLS) Kon guracja MDA:
forward@ → [email protected] (przekiero- wanie)
store@ → store (zapis lokalny) Wiadomo±ci przychodz¡ce ltrowane programem SpamAssassin Test pierwszy polegaª na sprawdzeniu dziaªania wymuszonego szyfrowania na porcie 587. swaks −−to [email protected] −−server shyym.com:587
=== Trying shyym.com:587... === Connected to shyym.com. <− 220 shyym.com ESMTP ready. −> EHLO reisub <− 250−shyym . com ... <− 250 STARTTLS −> MAIL FROM:
1 http://www.jetmore.org/john/code/swaks/
30 Serwer przedstawiª klientowi mo»liwo±¢ szyfrowania sesji. Klient ignoruj¡c ten fakt rozpocz¡ª standardow¡ transmisj¦ (polecenie MAIL FROM). Serwer zgodnie z oczekiwaniami zwróciª bª¡d. Kolejny test miaª na celu sprawdzenie, czy wª¡czenie szyfrowania po stronie klienta rozwi¡»e powstaªy problem. swaks −−to [email protected] −−server shyym.com:587 −−t l s
=== Trying shyym.com:587... === Connected to shyym.com. <− 220 shyym.com ESMTP ready. −> EHLO reisub <− 250−shyym . com ... <− 250 STARTTLS −> STARTTLS <− 220 Go ahead === TLS started with cipher TLSv1.2:ECDHE−RSA−AES256−SHA:256 ... ~> MAIL FROM:
Po udanej negocjacji TLS transmisja wiadomo±ci z punktu widzenia klienta prze- biegªa bez zakªóce«. Moduª MTA serwera dokonaª nast¦pnie podziaªu odbiorców na lokalnych i zewn¦trznych. 2015/02/26 15:03:32 addresses split into local: ["[email protected]"]; external: []
Lista odbiorców zewn¦trznych byªa pusta. Moduª MTA zezwoliª z tego powodu klientowi na dostarczenie wiadomo±ci bez autoryzacji. Wiadomo±¢ wraz z list¡ od- biorców lokalnych zostaªa nast¦pnie przekazana do moduªu MDA w celu jej utrwa- lenia. 2015/02/26 15:03:34 ignoring storage of e−mail to [email protected] (unknown user)
31 Moduª MDA zignorowaª wiadomo±¢, poniewa» nie zawieraªa znanych odbiorców. Nast¦pnie testom poddane zostaªo dziaªanie ªa«cucha przetwarzania. W tym celu u»yty zostaª program SpamAssassin oraz testowa wiadomo±¢ GTUBE2 (ang. Ge- neric Test for Unsolicited Bulk Email). −> DATA <− 354 Go ahead . End your data with
Kolejny test polegaª na sprawdzeniu dziaªania moduªu MDA w trybie zapisu oraz przekierowania. Po przyj¦ciu e-maila do obu odbiorców, MDA dokonaª dyspo- zycji wiadomo±ci do odpowiednich podmoduªów. 2015/03/09 00:49:59 addresses split into local: ["[email protected]" "[email protected]"]; external: [] 2015/03/09 00:50:01 message from szymski@reisub stored 2015/03/09 00:50:02 smtp.SendMail(gmail−smtp−in.l.google.com, forwarder@shyym .com, [ [email protected]]) : OK 2015/03/09 00:50:02 message from szymski@reisub forwarded to ["[email protected]"]
Moduª Maildir zapisaª wiadomo±¢ w wyznaczonym miejscu: cat maildir/shyym/. store/cur/1425858601017775706.14481.0.5577006 791947779410\:2\, Date: Mon, 09 Mar 2015 00:49:59 +0100 To: [email protected],[email protected] From: szymski@reisub Subject: test Mon, 09 Mar 2015 00:49:59 +0100 X−Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
This is a test mailing
2 https://spamassassin.apache.org/gtube/gtube.txt
32 Moduª MSA przekierowaª wiadomo±¢ na skrzynk¦ zewn¦trzn¡:
6.1. Analiza wydajno±ciowa
Poszczególne krytyczne komponenty systemu zostaªy równie» poddane analizie wydajno±ciowej (ang. benchmark). J¦zyk Go udost¦pnia wbudowany system do te- stów i benchmarków. Dany fragment kodu mo»e by¢ wywoªany reprezentatywn¡ liczb¦ razy, po czym zwracany jest jego ±redni czas wykonania. Benchmarki przeprowadzane byªy na procesorze Intel Core i5-3317U taktowanym cz¦stotliwo±ci¡ 1.70GHz. Benchmark gªównego handlera moduªu MTA testowaª przekierowanie wiadomo- ±ci kierowanej do odbiorcy lokalnego do moduªu MDA. Za moduª MDA sªu»yªa atrapa. Benchmark przyniósª nast¦puj¡ce rezultaty: go t e s t −bench . PASS BenchmarkReceive 300000 4687ns/op 376B/op 10 allocs/op ok github.com/shyym/pdimail/mta 2.438s
Moduª jest w stanie zwery kowa¢ przeznaczenie wiadomo±ci w ci¡gu 5ms. Benchmark metody Store moduªu MDA testowaª zachowywanie wiadomo±ci do odbiorcy przekierowywanego, lokalnego oraz ignorowanego. U»yte zostaªy atrapy moduªów MSA i Maildir. Benchmark przyniósª nast¦puj¡ce rezultaty: go t e s t −bench . PASS BenchmarkStoreIgnore 1000000 1715 ns/op 129B/op 4 allocs/op BenchmarkStoreForward 100000 20084 ns/op 5243B/op 24 allocs/op BenchmarkStoreMaildir 1000000 1704 ns/op 112B/op 4 allocs/op ok github.com/shyym/pdimail/mda 5.680s
Sumaryczny czas przetwarzania wiadomo±ci dla odbiorcy ignorowanego wynosi poni»ej 10ms. Jest to wynik pozwalaj¡cy na dziaªanie serwera pocztowego nawet w warunkach zwi¦kszonej aktywno±ci nadawców spamu.
33 Dªugo±¢ odbierania wiadomo±ci w celu przekierowania wynika z mody kacji na- gªówków wiadomo±ci. Jest to jednak czas o rz¡d wielko±ci mniejszy od czasu sesji SMTP z docelowym MTA. Czas przetwarzania wiadomo±ci do zapisu jest na porównywalnym poziomie z wiadomo±ci¡ ignorowan¡. W rzeczywisto±ci jest on powi¦kszony o czas zapisu na dysk. Czas zapisu jest zmienn¡ niezale»n¡ od implementacji systemu, nie jest on zatem uwzgl¦dniony w analizie. 7. Podsumowanie
W ramach tej pracy wykonany zostaª projekt oraz implementacja systemu e-mail. System zostaª cz¦±ciowo oparty o istniej¡ce biblioteki, co pozwoliªo ograniczy¢ na- kªad pracy oraz zminimalizowa¢ ryzyko wyst¡pienia bª¦dów implementacyjnych po stronie autora. Przed stworzeniem projektu systemu wykonana zostaªa analiza istnie- j¡cych rozwi¡za«. Analiza wykazaªa brak istnienia systemu, który w opinii autora speªnia w caªo±ci postawione wymagania. System zostaª zaprojektowany z my±l¡ o poª¡czeniu kluczowych zalet analizowanych rozwi¡za«. Analiza znanych autorowi j¦zyków programowania wykazaªa stosowno±¢ u»ycia j¦zyka Go. Na podstawie projektu powstaªa implementacja systemu w tym j¦zyku. U»ycie Go pozwoliªo osi¡gn¡¢ po»¡dan¡ w systemie wysok¡ wydajno±¢ i przeno±no±¢. W celu obsªu»enia protokoªu SMTP wykorzystana zostaªa biblioteka smtpd. Im- plementacja obsªugi protokoªu IMAP nie zostaªa uj¦ta w tej pracy ze wzgl¦du na szerok¡ specy kacj¦ protokoªu oraz brak istniej¡cych bibliotek dla wybranego j¦zyka. System testowany byª w ±rodowisku produkcyjnym. Hostem dla systemu byª posiadany przez autora VPS. Autor skon gurowaª równie» rekordy DNS posiada- nej przez siebie domeny w celu zapewnienia zgodno±ci systemu z obowi¡zuj¡cymi standardami. Aplikacja kliencka uruchamiana byªa na komputerze osobistym autora. Testowanie miaªo na celu wykazanie poprawno±ci oraz niezawodno±ci dziaªania sys- temu. Istnieje du»o mo»liwo±ci rozwoju systemu. Przede wszystkim nale»y zaimplemen- towa¢ obsªug¦ protokoªu IMAP. System pozwala równie» na zast¡pienie poszczegól- nych moduªów autorskimi implementacjami odpowiadaj¡cymi cudzym potrzebom. Mo»na równie» rozszerzy¢ istniej¡ce komponenty systemu w celu wsparcia metod wery kacji nadawcy takich jak DKIM lub SPF. Pozwoliªoby to na jeszcze lepsz¡ wery kacj¦ u»yteczno±ci wiadomo±ci.
35 Bibliogra a
[1] Network Working Group, J. Klensin, 2008, RFC 5321: Simple Mail Transfer Protocol, https://tools.ietf.org/html/rfc5321, dost¦p 23.12.2014
[2] Network Working Group, J. Myers, Netscape Communications, 1999, RFC 2554: SMTP Service Extension for Authentication, https://tools.ietf.org/html/rfc2554, dost¦p 23.12.2014
[3] Network Working Group, P. Homan, 2002, RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security, https://tools.ietf.org/html/rfc3207, dost¦p 23.12.2014
[4] Network Working Group, R. Gellens, Qualcomm, J. Klensin, MCI, 1998, RFC 2476: Message Submission, https://tools.ietf.org/html/rfc2476, dost¦p 21.01.2015
[5] Karst Koymans, University of Amsterdam, 2013, Electronic mail Aka e-mail (or email according to Knuth), https://www.os3.nl/_media/2013-2014/courses/cia/email.pdf, dost¦p 20.01.2015
[6] The Go Authors, 2012, Eective Go, https://golang.org/doc/effective_go.html, dost¦p 26.01.2015
[7] Network Working Group, S. Josefsson, SJD, 2006, RFC 4648: The Base16, Base32, and Base64 Data Encodings, http://tools.ietf.org/html/rfc4648, dost¦p 25.02.2015
[8] Network Working Group, M. Crispin, University of Washington, 2003, RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL VERSION 4rev1, http://tools.ietf.org/html/rfc3501, dost¦p 28.02.2015
[9] Post x feature overview, http://www.postfix.org/features.html, dost¦p 07.03.2015
36 [10] mbox le containing mail messages, http://www.qmail.org/man/man5/mbox.html, dost¦p 07.03.2015
[11] Maildir, http://wiki.dovecot.org/MailboxFormat/Maildir, dost¦p 07.03.2015
[12] Maildir++, http://www.courier-mta.org/imap/README.maildirquota.html, dost¦p 07.03.2015
[13] M. Brain, HowStuWorks.com, 2003, How Spam Works, http://computer.howstuffworks.com/internet/basics/spam.htm, dost¦p 09.03.2015 A. J¦zyk Go
Go jest j¦zykiem strukturalnym o skªadni zbli»onej do j¦zyka C. Zostaª stwo- rzony z my±l¡ o wydajnych aplikacjach wielow¡tkowych, w zwi¡zku z czym kon- strukcje programowania równolegªego s¡ bardzo czytelne. Tworzenie lekkich w¡tków (ang. goroutines) ograniczone jest do u»ycia sªowa kluczowego go. Komunikacja mi¦- dzy w¡tkami odbywa si¦ zwykle za pomoc¡ kanaªów (ang. channels). Zachowanie kanaªów jest zbli»one do Unixowych potoków (ang. pipes). Kanaªy s¡ to zmienne, przez które mo»na przekazywa¢ inne zmienne. Przekazywanie zmiennych przez kanaª jest caªkowicie bezpieczne w¡tkowo. Operacja odczytu zmiennej z kanaªu jest bloku- j¡ca, tj. wykonanie w¡tku jest zawieszone do momentu pobrania danych z kanaªu. Operacja zapisu jest równie» domy±lnie blokuj¡ca, ale istnieje mo»liwo±¢ stworze- nia kanaªów buforowanych, do których zapis nie jest blokuj¡cy je±li bufor nie jest zapeªniony.
Wydruk A.1. Przykªad u»ycia kanaªów do komunikacji mi¦dzy w¡tkami func main ( ) { msg := make(chan string ) go func ( ) { msg <− "Hello " }() fmt. Print(<−msg) go func ( ) { msg <− "world!" }() fmt. Println(<−msg) }
38 Cech¡ wyró»niaj¡c¡ Go spo±ród innych j¦zyków jest nietypowe podej±cie do syn- chronizacji. Zamiast klasycznego blokowania dost¦pu do pami¦ci wspóªdzielonej za pomoc¡ wyª¡cznych blokad (ang. mutex), twórcy j¦zyka sugeruj¡ u»ycie w¡tków dedykowanych obiektom i komunikacj¦ z tymi w¡tkami za pomoc¡ kanaªów. Wydruk A.2. Dost¦p wspóªdzielony przez komunikacj¦ func main ( ) { n := NewNumber(0) go func (){ for { n . Add(1) } }() for { fmt.Println(n.Get()) } } type Number struct { data int r e q u e s t s chan interface {} } type addReq int type getReq chan int func NewNumber( x int ) ∗Number { n := &Number{x, make(chan interface {})} go func (n ∗Number) { for req := range n.requests { switch req := req . ( type ){ case addReq : n . data += int ( req ) case getReq : req <− n . data } } }(n) return n } func (n ∗Number) Add(x int ){ n.requests <− addReq ( x ) } func (n ∗Number) Get() int { respCh := make( getReq ) n.requests <− respCh return <−respCh }
39 Go jest j¦zykiem wysoce dostosowanym do tworzenia wysoko wydajnych serwe- rów. Tworzenie lekkiego w¡tku dla ka»dego poª¡czenia nie stanowi problemu, po- niewa» wbudowane w program ±rodowisko uruchomieniowe nie przeª¡cza kontekstu bez potrzeby. Opisane wcze±niej kanaªy pozwalaj¡ równie» na tworzenie prostych konstrukcji ograniczaj¡cych liczb¦ poª¡cze«.
Wydruk A.3. Ograniczanie liczby jednoczesnych poª¡cze« var l i m i t e r = make(chan struct {}, maxConnections) func ( s ∗ session) run() { go func (){ select { case l i m i t e r <− struct {}{}: s . s e r v e ( ) <−l i m i t e r default : s. reject("Too many connections .") } }() }
40