UNIVERZITET U BIHAĆU TEHNIĈKI FAKULTET BIHAĆ

DIPLOMSKI RAD

IMPLEMENTACIJA MAIL SERVERA U JAVA PROGRAMSKOM JEZIKU

Hodžić Adis

Bihać, februar 2011

Hodţić Adis IMPLEMENTACIJA MAIL SERVERA U JAVA PROGRAMSKOM JEZIKU

SAŽETAK: Tema ovog rada je implementacija SMTP i POP3 mail servera pomoću programskog jezika JAVA. Rad obrađuje problematiku mail servera, opisuje standarde i protokole koji čine jedan mail server. Također su prezentirani sigurnosni mehanizmi koji se koriste u praksi te način njihove upotrebe. U sklopu rada urađena je i aplikacija u programskom jeziku JAVA, objašnjen postupak izrade, i način korištenja aplikacije. Kljuĉne rijeĉi: Mail, Server, JAVA, SMTP, POP3

IMPLEMENTATION OF MAIL SERVER IN JAVA PROGRAMMING LANGUAGE

ABSTRACT: This paper is based on topic regarding implementation of SMTP and POP3 mail server with JAVA programming language. Paper is explaining fundamental standards and protocols that every modern Mail Server system must adopt. Also, here are presented security mechanisms that are used by Mail Server systems today. Additionally, we have developed „Mail server“ application in JAVA programming language and explained structure, development process and use of application „Mail server“. Keywords: Mail, Server, JAVA, SMTP, POP3

2

SADRŽAJ
POPIS SLIKA .................................................................................................................................. 5 POPIS TABELA .............................................................................................................................. 6 POPIS SKRAĆENICA ....................................................................................................................... 6 1. UVOD ....................................................................................................................................... 7 2. MAIL SERVERI ........................................................................................................................... 9 2.1 Općenito o internetu............................................................................................................ 9 2.1.1 Historija interneta .................................................................................................................. 9 2.1.2 Arhitektura interneta ........................................................................................................... 10 2.2 DNS – Domain Name System ............................................................................................. 12 2.3 Klijent/Server model ......................................................................................................... 15 2.4 RFC i IETF .......................................................................................................................... 15 2.5 SMTP – Simple Mail Transfer Protocol ............................................................................... 17 2.5.1 SMTP naredbe ...................................................................................................................... 18 2.5.2 SMTP odgovori ..................................................................................................................... 22 2.5.3 Sekvence odgovora u odnosu na stanje sesije ..................................................................... 23 2.5.4 Dijagram toka SMTP servera ................................................................................................ 24 2.5.5 Primjer sesije između SMTP servera i klijenta ...................................................................... 25 2.6 POP3 – Post Office Protocol verzija 3 ................................................................................. 25 2.6.1 Stanje autorizacije (Authorisation state).............................................................................. 26 2.6.2 Stanje transakcije (Transaction State) .................................................................................. 27 2.6.3 Stanje izvršavanja (Update state) ......................................................................................... 30 2.6.4 Dodatne POP3 naredbe ........................................................................................................ 31 2.6.5 Dijagram toka POP3 servera ................................................................................................. 32 2.6.6 Primjer sesije između POP3 servera i klijenta ...................................................................... 33 2.7 IMAP – Internet Message Access Protocol.......................................................................... 33 2.8 MIME – Multipurpose Internet Mail Extensions ................................................................. 34 2.8.1 MIME zaglavlja...................................................................................................................... 34 3. SIGURNOST MAILA ................................................................................................................. 39 3.1 Sigurnost prilikom ostvarivanja konekcije klijenta na server ............................................... 39 3.1.1 Blacklist ................................................................................................................................. 40 3.1.2 SSL – Secure Socket Layer i TLS – Transport Layer Security ................................................. 40 3.1.3 SPF – Sender Policy Framework ........................................................................................... 41 3.2 Sigurnost unutar mail poruke ............................................................................................ 42 3

3.2.1 PEM – Privacy Enhanced Mail .............................................................................................. 42 3.2.2 S/MIME – Secure/MIME ....................................................................................................... 42 3.2.3 OpenPGP – Open Pretty Good Privacy ................................................................................. 43 4. IMPLEMENTACIJA MAIL SERVERA SA PROTOKOLIMA SMTP I POP3 U JAVA PROGRAMSKOM JEZIKU ........................................................................................................................................ 45 4.1 Model baze podataka ........................................................................................................ 45 4.2 Klasni dijagram aplikacije .................................................................................................. 46 4.3 GUI aplikacije .................................................................................................................... 52 4.4 Log datoteke ..................................................................................................................... 56 4.5 Settings datoteka .............................................................................................................. 56 4.6 Primjer rada aplikacije....................................................................................................... 57 4.7 Ograničenja ...................................................................................................................... 58 5. ZAKLJUČAK ............................................................................................................................. 59 LITERATURA ............................................................................................................................... 60 PRILOZI ...................................................................................................................................... 62

4

POPIS SLIKA Indeks slike Slika 1.1 Slika 2.1 Slika 2.2 Slika 2.3 Slika 2.4 Slika 2.5 Slika 2.6 Slika 2.7 Slika 3.1 Slika 4.1 Slika 4.2 Slika 4.3 Slika 4.4 Slika 4.5 Slika 4.6 Slika 4.7 Slika 4.8 Slika 4.9 Slika 4.10 Slika 4.11 Slika 4.12 Slika 4.13 Slika 4.14 Slika 4.15 Slika 4.16 Slika 4.17 Slika 4.18 Slika 4.19 Slika 4.20 Naziv slike IBM 7094 Arhitektura interneta, slojevi Šematski prikaz hijerarhije DNS servera Format DNS RR zapisa Model SMTP protokola Dijagram toka SMTP servera Dijagram toka POP3 servera Primjer kodiranja pomoću Base64 algoritma Šematski prikaz uspostavljanja TLS konekcije ER model baze podataka Klasni dijagram aplikacije Klasa mysqlUtil Klasa Folder Klasa User Klasa Message Klasa POPConnection Klasa SMTPConnection Klasa POPWorker Klasa SMTPWorker Klasa updateQuota Klasa MainGUI Početni izgled aplikacije SMTP server pokrenut Izgled taba POP3 Server POP3 server pokrenut Tab User Administration Tab About Testna mail poruka pošiljaoca Testna mail poruka uspješno primljena Stranica 8 12 14 15 18 25 34 39 43 48 49 49 50 50 51 51 52 52 53 53 54 54 55 55 56 57 57 59 60

5

POPIS TABELA Indeks tabele Tabela 2.1 Tabela 2.2 Naziv tabele Najvaţniji tipovi domena u DNS RR zapisu Base64 znakovi Stranica 16 39

POPIS SKRAĆENICA

Skraćenica CTSS RFC PC ARPA WWW DNS FTP SMTP TCP UDP IP CRLF POP MIME DNSBL SSL TLS SPF PEM GUI

Značenje Compatible Time-Sharing System Request For Comments Personal Computer Advanced Research Project Agency World Wide Web Domain Name System File Transfer Protocol Simple Mail Transfer Protocol Transmission Control Protocol User Datagram Protocol Internet Protocol Carriage Return Line Feed Post Office Protocol Multipurpose Internet Mail Extensions DNS based BlackList Secure Socket Layer Transport Layer Security Sender Policy Framework Privacy Enhanced Mail Graphical User Interface

6

1. UVOD Priča o mailu počinje 1961. godine, koja je prema ljudskom poimanju vremena istekla i ne baš tako davno, meĎutim, iz perspektive računarstva, radi se o samom praskozorju informatičke tehnologije koju danas poznajemo. Na MIT-u (Massachusetts Institute of Technology, USA) razvijen je CTSS (Compatible Time-Sharing System). Osnovna namjena ovog programa je bila višekorisničko logiranje sa udaljenih terminala i pohranjivanje datoteka na disk (konkretno, radilo se je o IBM-ovom 7094 računaru, sa 32Kb memorije i brzinom od 0,35 MIPS-a, a koštao je oko 3,5 miliona američkih dolara[5]).

Slika 1.1: IBM 7094 [6] Takav način logiranja na sistem je ubrzo doveo do situacije da su pojedini dokumenti bili nazivani „to user“ i pohranjivani u javne direktorije (engl. Public Directory), pa je korisnik kada se loguje na sistem mogao pregledati direktorij i vidjeti da li su neki dokumenti naslovljeni na njega, te ih pročitati, odštampati, odgovoriti koristeći sličnu metodologiju itd. Naravno ovakav pristup ne samo da je bio neprihvatljiv iz privatnih razloga (dokumente je mogao čitati bilo ko), bio je i vrlo nepraktičan iz razloga što nije postojao način dostave poruke tačno odreĎenim korisnicima (zamislimo listanje kroz par stotina ili hiljada dokumenata u jednom folderu) pa se je ubrzo javila ideja da se ovakva razmjena podataka standardizira. Tada se prvi put javlja mail komanda, čije je korištenje imalo za posljedicu da se navedeni dokument dostavi korisniku u njegov Mail Box direktorij koji drugi korisnici nisu mogli pročitati. Zanimljivo je da je menadţment MIT-a prvo odbio ovu ideju jer su je smatrali nekorisnom i skupom, meĎutim ubrzo su uvidjeli da ovakva razmjena informacija bitno utječe na komunikaciju i produktivnost te su odobrili pisanje software-a za mail komandu koji je uraĎen 1965. godine a čiji kod moţete vidjeti u dodatku A.

7

Već 1968. godine javlja se ideja da se sve mašine pod pokroviteljstvom ARPA-e (Advanded Research Project Agency) poveţu te im se omogući meĎusobna komunikacija.[7] Uskoro se pravi više RFC (Request For Comments) dokumenata koji obraĎuju problem „Mail Box protokola“, odnosno načina slanja mail-a preko ARPANet-a odreĎenom korisniku. Prvi RFC spomenut u ovom kontekstu je RFC 196, „Mail Box Protocol“, napisan od strane R. W. Watson 20.7.1971. godine. U martu 1972. godine Ray Tomlinson piše jednostavne programe zvane SNDMSG i READMAIL i iako je mail već uspješno kruţio ARPANet-om nekoliko godina (pojašnjenje, često RFC dokumenti nastaju nakon što se neka tehnologija praktično isproba, i onda sluţe kao skup pravila koje ostali moraju implementirati da bi bili kompatibilni sa tom tehnologijom) njegov najveći doprinos je uvoĎenje „ @“ znaka u mail, koji je razdvajao korisničko ime (Username) od adrese računara (Host Name). Čak su i u protokolu koji prvenstveno sluţi za slanje datoteka (FTP – File Transfer Protocol) dodane komande koje su omogućavale slanje maila u RFC-u 385. Naravno, uslijedio je još niz raznih RFC dokumenata meĎutim najvaţniji je RFC 772, „Mail Transfer Protocol“ napisan u septembru 1980. godine od strane S. Sluizer i J. Postel koji je bio preteča SMTP protokolu koji se danas koristi za slanje maila. E-mail ili mail, danas najpopularnija izvedenica od termina elektronska pošta, je svoju popularnost stekao u najranijim danima svog nastanka, te je zadrţao i do danas i zato slovi za najpopularniju i najkorišteniju aplikaciju interneta ikad. Studija Radicati Group-a[8] uraĎena u maju 2009. godine kaţe da u svijetu postoji oko 1.9 milijardi korisnika maila, koji imaju oko 2.9 milijardi korisničkih računa, te da se dnevno pošalje stotine milijardi mail poruka. I zaista, u današnje vrijeme je gotovo nemoguće da osoba koja se bavi bilo kojim zanimanjem, pogotovo zanimanjem koje vezano za online poslovanje, nema barem jedan mail račun. Sve kompanije, firme i preduzeća koja imalo vode računa o svom imidţu imaju barem jedan mail na koji im korisnici mogu poslati razne upite i komentare, a da ne spominjemo internu komunikaciju zaposlenika jedne firme bilo da je ona smještena u jednoj zgradi, ili na više kontinenata. Mail je omogućio jednostavno, jeftino i gotovo trenutno slanje poruka na bilo koji kraj svijeta, i zaista je teško da ćemo u budućnosti vidjeti neke drastične promjene u načinu njegovog rada, a i popularnosti.

8

2. MAIL SERVERI E-mail je samo jedna u moru aplikacija koje se koriste na internetu i prije nego što se počnemo baviti problematikom mail servera, prvo ćemo u kratkim crtama pokušati objasniti infrastrukturu na koju se oslanjaju sve internet aplikacije, pa meĎu njima i mail serveri.

2.1 Općenito o internetu Danas vjerovatno ne postoji civiliziran čovjek koji ne zna za pojam internet. Ipak, iako je to opće poznat termin za tehnologiju koja je čak od strane udruge Internet Society proglašena ljudskim dobrom[1] (što internet svrstava rame uz rame sa vodom, zrakom itd.), vrlo je malen broj ljudi koji malo dublje razumiju internet, a da ne govorimo o potpunom poznavanju kompleksnosti mehanizama na kojima on počiva. Cilj ovog rada i nije detaljno objašnjavanje principa rada interneta (za problematiku tog obima bilo bi potrebno više knjiga), pa ćemo ukratko objasniti osnovne pojmove vezane za internet kako bi mogli razumjeti daljnje izlaganje vezano za temu ovog diplomskog, a to su e-mail serveri. Postoji mnogo definicija o tome šta je internet. Neke od njih (u slobodnom prijevodu sa engleskog) glase:  Računarska mreţa koja se sastoji od svjetske mreţe računarskih mreţa koje koriste TCP/IP mreţne protokole za slanje i primanje podataka.[9]  Internet je globalni sistem meĎusobno povezanih računarskih mreţa koje pomoću TCP/IP protokola usluţuju milijarde korisnika širom svijeta. [10]  Javno dostupan meĎunarodni, odnosno globalni sistem meĎusobno povezanih računara, zajedno s informacijama i uslugama koje povezani računari mogu pruţati korisnicima, u kojemu se koristi skup standardnih komunikacijskih protokola. [2] Dakle, općenito govoreći, radi se o mreţi koja povezuje računare i omogućava njihovu meĎusobnu komunikaciju. Iako se pod pojmom „računar“ korištenim u definicijama većinom misli na PC računare (koji zaista i jesu bili gotovo jedini ureĎaji spajani u mreţu), u današnje vrijeme se sve više na mreţu spajaju i razni drugi ureĎaji kao što su mobiteli, tableti, televizori, kuhinjski aparati, automobili itd. Trendovi govore da će uskoro PC izgubiti primat mreţnih ureĎaja i da će daleko više biti „ne-PC“ ureĎaja na internetu.

2.1.1 Historija interneta Počeci interneta su vezani za rane šezdesete godine prošlog stoljeća. U to vrijeme u svijetu su prevladavale telefonske mreţe koje su zasnovane na tehnologiji komutiranja vodova, za koju je najznačajnije spomenuti da omogućuje povezivanje (samo) dva ureĎaja i to na način da ima se dodijeli i rezerviše odreĎen dio propusnog opsega na linku ili linkovima izmeĎu njih. Ovakav način je sasvim dovoljan za potrebe telefonije, a to je slanje ljudskog glasa preko mreţe (koristi se i danas), meĎutim korištenje takvog sistema prijenosa podataka je vrlo nepraktično i neoptimizirano za računare (osnova računarske komunikacije nije glas već bit), a i ograničenje na samo dva istovremena sudionika u komunikacijskoj sesiji je ozbiljan nedostatak. Adekvatna zamjena za komutiranje vodova napravljena je u vidu komutiranja paketa (prvi rad o tome objavio je Leonard Kleinrock 1961. godine). Takav način
9

komunikacije omogućavao je da sve svoje poruke koje ţele poslati, podijele na manje jedinice nazvane paketi, adresiraju ih na odreĎeni računar i pošalju u mreţu. Kad se naĎu u mreţi „brigu“ o paketima preuzimaju mreţni ureĎaji (switchevi, routeri, itd) koji na osnovu svojih tabela rutiranja odreĎeni paket prosljeĎuju na linkove koji vode prema tom odreĎenom računaru. Na ovaj način vrlo su efektno postignute dvije stvari: 1. Komunikacija je prilagoĎena računarima (prijenos bitova umjesto glasa) 2. Niko nije imao ekskluzivitet na mreţne resurse (jer niko ne moţe rezervisati odreĎen propusni opseg samo za sebe, u principu svi mogu slati koliko hoće paketa u mreţu). Ovakav način komunikacije izmeĎu računara prvi put je uveo ARPANet (mreţa u koju su bili povezani računari pod pokroviteljstvom ARPA-e) koja je do 1972. godine brojala čak 15 računara. Uskoro javlja veliki broj drugih mreţa graĎenih po uzoru na ARPANet, te se jednostavno dolazi do trenutka da je vrijeme da se sve te mreţe objedine u jednu, što su i obavili Vinton Cerf i Robert Khan 1974. godine. Taj čin povezivanja mreţa (internetting, engl.) je doveo i do današnjeg imena interneta. Do kraja sedamdesetih godina broj računara u mreţi je narastao na 200, a u 80-im godinama internet konačno probija granice SAD-a, i u roku od nekoliko godina postaje globalna mreţa. Od tada pa do danas, ako izuzmemo povećanje propusnog opsega i omasovljenja beţičnog pristupa internetu, internet se nije gotovo nikako mijenjao i slovi za jedini ljudski proizvod koji radi besprekidno od trenutka njegovog nastajanja pa do danas. [3]

2.1.2 Arhitektura interneta Internet svoju robusnost najviše moţe zahvaliti svojoj slojevitoj (layered, engl.) arhitekturi. Kao što moţemo vidjeti na slici 2.1 internet je graĎen iz pet slojeva, a to su: 1. Aplikativni sloj (Aplication layer) 2. Transportni sloj (Transport layer) 3. Mreţni sloj (Network layer) 4. Sloj veze (Data layer) 5. Fizički sloj (Phisical layer) Najvaţnija osobina ovakve arhitekture interneta je u tome da su slojevi prilično nezavisni jedan od drugog. Naravno svi slojevi moraju pruţati predviĎene usluge slojevima iznad i ispod sebe (ako postoje), ali uzmimo na primjer da iz nekog razloga ţelimo kompletno izmijeniti transportni sloj. To je sasvim moguće uraditi i jedino što bi nam bilo ograničenje je da pruţimo predviĎene usluge sloju iznad (aplikativnom sloju) i sloju ispod (mreţnom sloju), a način na koji će sam transportni sloj obavljati svoj posao moţemo kompletno izmijeniti. Takve izmjene su se dosad jedino dešavale u aplikativnom i fizičkom sloju, dok u „srednjim“ slojevima do sad nije dolazilo promjena u načinu njihovog rada. Na primjer, u aplikativnom sloju se, kao što i samo ime govori, izvode sve naše aplikacije (mail, web, ftp, skype, itd.). Iako većina tih aplikacija koristi standardizirane protokole, ne postoji nikakvo ograničenje da neko napiše svoju aplikaciju, sa svojim protokolima (kao što je to na primjer učinio skype), sve dok god ta aplikacija komunicira sa transportnim slojem na za to predviĎen način. Iako ovakva sloboda moţda izgleda zbunjujuće i nepotrebno, uzmimo za primjer beţične mreţe. Zamislimo da je fizički sloj ostao ograničen da se u njemu mogu koristiti samo ţice kao medij prijenos podataka (što i jest bio gotovo jedini medij i ranim danima interneta), onda bi zaista
10

bilo pitanje da li bi ikad beţične tehnologije doţivjele ekspanziju kakvu imamo danas. Beţične mreţe rade na potpuno drugačijem principu od mreţa koje koriste ţice kao medij, meĎutim one pruţaju iste usluge sloju veze, tako da su potpuno u skladu sa propisanom arhitekturom interneta. [3]

Aplikativni sloj

Transportni sloj

Mrežni sloj

Sloj veze

Fizički sloj

Slika 2.1: Arhitektura interneta, slojevi [3]

Aplikativni sloj: Kao što je već prije spomenuto na aplikativnom sloju se izvode naše aplikacije. To je sloj u kojem programi zapravo vrše interakciju sa korisnicima i on je najraznolikiji i najbogatiji sadrţajem od svih ostalih slojeva, što je i sasvim razumljivo s obzirom na ulogu koju ima. Primjeri aplikacija i protokola koje se izvršavaju na njima su WWW (World Wide Web), DNS (Domain Name System), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), itd. [3] Transportni sloj: Na transportnom sloju nalazimo 2 protokola, a to su TCP (Transmission Control Protocol) i UDP (User Datagram Protocol) i prilikom prenošenja poruka sa aplikativnog sloja koristimo jedan od njih. Glavne razlike su u tome da TCP obezbjeĎuje garantovan prijenos poruka (dakle TCP protokol garantira da će sve poruke prenijeti na odredište, neoštećene i po redoslijedu), dok UDP ne garantira takvu isporuku, ali će napraviti najbolji pokušaj. TCP se koristi kod aplikacija koje ne tolerišu greške (mail, web, FTP, itd.), dok UDP kod aplikacija kojima gubitak odreĎenog broja paketa ne predstavlja značajan nedostatak (prijenos videa, audio zapisa, itd.). [3]

11

Mrežni sloj: Zadaća mreţnog sloja je da segmente dobijene iz transportnog sloja pretvori u datagrame i proslijedi dalje kroz mreţu. Na mreţnom sloju nalazimo čuveni IP (Internet Protocol) čija je glavna zadaća da pomoću svojih tabela rutiranja proslijeĎuje (rutira, usmjerava) datagrame na odreĎene linkove. IP se često smatra protokolom koji drţi čitav internet na okupu. [3] Sloj veze: Sloj veze ima zadaću da datagrame dobijene iz mreţnog sloja pretvori u format koji se naziva okvir, te ih proslijedi do slijedećeg čvora u mreţi. Najviše saobraćaja na internetu se dešava upravo u mreţnom i sloju veze, jer se mreţni sloj i sloj veze uvelike naslanjaju jedan na drugi što i nije slučaj sa ostalim slojevima. Uzmimo za primjer jedan datagram, koji mreţni sloj treba poslati do odreĎenog čvora. Mreţni čvor će pročitati IP adresu čvora kojem treba dostaviti datagram, te na osnovu svoje tabele rutiranja isporučiti datagram na odreĎeni link. Tu posao preuzima sloj veze koji ima zadaću da taj okvir (enkapsulirani datagram) proslijedi do drugog kraja linka. Kada okvir doĎe do kraja linka, sloj veze dekapsulira okvir, te datagram predaje mreţnom sloju, koji opet provjerava IP adresu da vidi koje je odredište datagrama, pa ga ili isporučuje sloju iznad, ili šalje dalje istom procedurom. Ako uzmemo u obzir da izmeĎu dva sistema koja komuniciraju putem mreţe, obično imamo jako puno čvorova, jasno je da daleko veća vjerovatnost da će odreĎeni datagram biti namijenjen za slanje dalje, nego da će biti isporučen transportnom sloju. [3] Fiziĉki sloj: Zadaća fizičkog sloja je najjednostavnija za objasniti. Njegova uloga je da okvire dobijene iz sloja veze, pretvori u pojedinačne bitove i te bitove isporuči na medij koji se koristi za prijenos izmeĎu dva čvora. [3]

2.2 DNS – Domain Name System DNS je jedna „nevidljiva“, a ipak jako vaţna usluga interneta koju praktički stalno koristimo. Moţda bi se ovdje moglo javiti pitanje zašto samo u uvodu izjavili da je mail najpopularnija aplikacija na internetu, a iz prethodne rečenice se moţe izvesti drugačiji zaključak, meĎutim razlog je taj što se DNS ne smatra aplikacijom u pravom smislu već više kao usluga, ili dodatak (feature, engl.) internetu. Uloga DNS-a je da obezbijedi prevoĎenje alfa-numeričkih adresa interneta (koje su pogodne ljudima za pamćenje i rad sa njima) u adrese u IP formatu (koje su pogodne za računare). Dakle, svaki put kada u web pretraţivač ukucamo www.google.com, ili neku drugu adresu, naš računar šalje upit DNS serveru da mu dostavi koja je to IP adresa računara čije je ime www.google.com, nakon čega računar ima potrebne podatke da uspostavi konekciju google-ovim serverom. Naravno, nama je puno lakše zapamtiti adrese pisane alfa-numeričkim znakovima, nego da npr. za posjetu prethodno navedenoj stranici moramo u web pretraţivač kucati 125.111.32.42, još ako uzmemo u obzir da se IP adrese računara mogu promijeniti, onda moţemo zamisliti koliko vaţnu ulogu igra DNS u našem svakodnevnom surfanju. Isto tako, ako ţelimo poslati mail odreĎenom korisniku, mail ćemo nasloviti u obliku korisnik@domena.com. Program zaduţen za isporuku maila će prvo DNS serveru poslati upit sa domenom domena.com te zahtijevati MX zapis, nakon što dobije IP adresu računara zaduţenog za tu domenu, uspostaviti konekciju sa istim, i tek onda isporučiti mail navedenom korisniku (ili barem pokušati). [4]

12

DNS serveri su hijerarhijski organizovani i obično se dijele na 3 grupe:  Korjeni DNS serveri (root, engl.): serveri koji sadrţe podatke o lokacijama TLD servera  TLD DNS server (Top Level Domain): Serveri koji sadrţe podatke o nadleţnim serverima za pojedinu TL domenu (npr, com, org, edu, gov, itd.)  Nadleţni DNS serveri: Serveri zaduţeni za poddomene TL domena (npr. tfb.com, vlada.gov, itd.) Na slijedećoj slici moţemo vidjeti šematski prikaz hijerarhije DNS servera:

Korjeni DNS Server

DNS server za domenu com

DNS server za domenu org
DNS server za google.co m DNS server za pbs.org

DNS server za domenu edu

DNS server za yahoo.com

DNS server za poly.edu

DNS server za umass.edu

Slika 2.3: Šematski prikaz hijerarhije DNS servera [3]

13

Jedan RR zapis (Resource Record, engl.) u DNS bazi ima slijedeću strukturu[11]:

NAME TYPE CLASS TTL RDLENGTH RDATA
Slika 2.3: Format DNS RR zapisa Name: Predstavlja ime domene. Type: Predstavlja tip domene. Najvaţniji tipovi domena se mogu pronaći u tabeli 2.1. Class: Predstavlja klasu domene. Za podatke na internetu ovaj tip uvijek ima vrijednost IN, i vrlo rijetko moţemo susresti zapis sa drugom vrijednosti. TTL: Time To Live, odnosno vrijeme u sekundama koliko će dati zapis biti validan. RDLength: Broj koji označava duţinu (u bajtovima) RDATA polja RData: Znakovni opis RR-a.

14

Tabela 2.1: Najvažniji tipovi domena u DNS RR zapisu[4] Tip Znaĉenje Vrijednost Početak pouzdanih informacija Parametri za aktuelnu DNS SOA zonu IP adresa računara 32-bitni broj A E-mail Prioritetna domena za MX primanje maila Server imena Ime servera za aktuelnu NS domenu Kanonsko ime Ime domene CNAME Pokazivač Alias IP adrese PTR Opis računara Opis Hardware-a (tekst) HINFO Tekst ASCII tekst TXT 2.3 Klijent/Server model Klijent/server tip aplikacija je najčešći oblik koji susrećemo kod gotovo svih aplikacija na internetu. Radi se o modelu distribucije aplikacije na usluţni dio, koji obavlja server, i na dio aplikacije koji zahtijeva uslugu, što obično radi klijent. Iako je ovakva definicija prilično razumljiva, vrlo je teško podvući jasnu crtu izmeĎu klijentskog i serverskog dijela aplikacije. Ljudi većinom pod pojmom server podrazumijevaju velike, jake i skupe računare čija je uloga da budu uvijek dostupni i pruţaju nam usluge, u suštini to nije baš precizna definicija servera. Jedna od najpreciznijih definicija servera bi bila da je server svaki računar, odnosno, da budemo još precizniji, svaki proces u računaru, koji u odreĎenom vremenskom trenutku pruţa uslugu nekom procesu u drugom računaru, ili čak i drugom procesu u istom računaru. Naravno definicija klijenta bi bila obratna, to je svaki računarski proces koji u odreĎenom trenutku zahtijeva neku uslugu od drugog računarskog procesa i pri tom nije bitno da li je taj drugi računarski proces smješten unutar istog računara, ili nekog vanjskog. Pošto se unutar jednog računara gotovo nikad ne izvodi samo jedan proces, pa čak i procesi dodijeljeni samo jednoj aplikaciji mogu imati potpuno različite uloge, jasno je zašto je teško govoriti o jasnoj razlici izmeĎu servera i klijenta. Ipak, u ovom radu ćemo koristiti pojednostavljeni i idealizirani model, koji podrazumijeva da je server računar koji pruţa usluge, a klijent računar koji zahtijeva usluge. Analogno tome, mail serverom ćemo smatrati računar čija je glavna zadaća da primi mail za registrirane klijente, te iste dostavi na zahtjev tih klijenata. Klijente ćemo smatrati računarima koji sluţe za povezivanje na server radi slanja ili pregledanja mail poruka. 2.4 RFC i IETF IETF [12] – Internet Engineering Task Force je velika, otvorena internacionalna zajednica mreţnih dizajnera, operatera, posluţitelja i istraţivača kojima je zajednički cilj evolucija i neometan rad interneta. Sav rad unutar IETF-a se dijeli na radne grupe (working groups, engl.) ovisno o sferi zanimanja (rutiranje, transport, sigurnost, itd.). Radne grupe su članice odreĎenog područja na čijem čelu se nalazi direktor područja (Area Director) koji su članovi IESG-a[13] (Internet Engineering Steering Group). Nadzorni odbor je predstavljen u obliku IAB-a[14] (Internet Architecture Bord) čija je glavna uloga da odlučuje o kvaliteti rada IESG-a, te ako isti ne uspiju dovesti rad do potrebne kvalitete, da isti šalju na doradu, ili
15

jednostavno odbace. Misija IETF-a se moţe pročitati u RFC-u 3935[15], koji u prvoj rečenici kaţe da je „cilj ITEF-a da učini da internet radi bolje“. IETF ţeli da proizvede kvalitetne tehničke i inţinjerske dokumente koji će uticati na razvoj, korištenje i upravljanje internetom, tako da on na kraju radi bolje. U ove dokumente su uključeni standardi protokola, najbolje prakse, ali i informacioni dokumenti raznih vrsta. Konačni proizvod IETF-a su RFC dokumenti, koji na kraju predstavljaju standard. Koraci koji su potrebni da bi neki dokument postao RFC standard su: 1. Objaviti dokument kao Internet – Draft 2. Dobiti komentare na taj dokument 3. Doraditi dokument na osnovu komentara 4. Ponoviti korake od 1 do 3 nekoliko puta 5. Zamoliti direktora područja da taj dokument dostavi radnoj grupi u čijoj je domeni tema dokumenta 6. Primiti ocjene šireg IETF članstva. 7. Napraviti izmjene zahtijevane od IESG-a (što moţe značiti i odustajanje od procesa standardizacije) 8. Sačekati da dokument bude objavljen kao RFC standard. Kao što se moţe vidjeti, proces standardizacije je vrlo dug (moţe trajati i više godina) i zato i nema puno RFC dokumenata, tek oko 5000. Nije rijedak slučaj da neki standard stekne masovnu primjenu prije nego zvanično postane standard. Ipak, posljedica ovako sporog procesa je da se RFC dokumenti nikad ne mijenjaju! Ono što moţe uslijediti je novi RFC dokument koji će neki standard proglasiti zastarjelim, ali se prethodni RFC dokument nikad ne mijenja. Iako na prvi pogled izgleda da je ovaj proces prespor i da na neki način sputava nove tehnologije, ipak treba imati na umu broj korisnika interneta danas, biznisa koji se odvija preko interneta i koji jednostavno ne trpi zastoje u radu, pa onda postaje jasno zašto se novi standardi prvo izuzetno paţljivo ispitaju, i objavljuju kada su gotovo bez greške. RFC dokumenti nisu uvjetovani, meĎutim, globalno su općeprihvaćeni kao standard i svako ko ţeli da njegova aplikacija bude u mogućnosti da komunicira sa aplikacijama iste tematike na internetu, jednostavno se mora povinovati pravilima koja stoje u nadreĎenom RFC dokumentu. Nakon ovih nekoliko odjeljaka, nadam se da smo dovoljno jasno objasnili osnovne stvari koje je potrebno znati da bi se moglo razgovarati problematici mail servera (u priloţenim referencama se moţe saznati više o svakoj temi). Da bi neki mail server bio u mogućnosti razmjenjivati poruke sa drugim mail serverima, potrebni su, naravno, standardi, koji postoje, i čiji opis slijedi u narednim odjeljcima.

16

2.5 SMTP – Simple Mail Transfer Protocol SMTP protokol je prvi put opisan u dokumentu RFC 821[16] još 1982. godine, meĎutim doţivio je brojne nadogradnje i sad se taj dokument smatra zastarjelim. Trenutno aktuelna verzija SMTP protokola se moţe naći u dokumentu RFC 5321[17]. Glavna zadaća SMTP protokola je pouzdani i efikasni prijenos maila. SMTP nije ograničen u smislu transportnog podsistema, ali zahtijeva pouzdani i garantovani prijenos podataka (što u današnjoj arhitekturi interneta obezbjeĎuje TCP protokol). Model SMTP protokola se moţe vidjeti na slici 2.4:

Korisnik

SMTP naredbe/odgovori i mail
File System

File System

SMTP klijent

SMTP server

Slika 2.4: Model SMTP protokola Kada SMTP klijent ţeli poslati mail na neki SMTP server, on ostvaruje dvosmjernu konekciju sa tim serverom. Slanje maila na jedan ili više servera je u potpunosti odgovornost klijenta i on je duţan da korisnika obavijesti ako je u nemogućnosti da to uradi. Server moţe biti krajnja destinacija maila (znači da je korisnik na čije ime je poslan mail registrovan na tom serveru), moţe biti „relay“ server (što znači da moţe preuzeti ulogu SMTP klijenta nakon što primi poruku i poslati je dalje), ili „gateway“ server (što znači da moţe poruku poslati nekim drugim protokolom drugom serveru). SMTP naredbe (commands, engl.) generira klijent i šalje serveru, dok SMTP odgovori (responses, engl.) predstavljaju komunikaciju servera ka klijentu. Iz prethodno napisanog se moţe zaključiti da se slanje maila moţe dogoditi direktnom konekcijom klijenta na server, ili pak mail moţe proći kroz više čvorova na putu do svog odredišta. U oba slučaja, kada server izda pozitivan odgovor nakon primanja maila, mail postaje njegova odgovornost, te sada on mora ili isporučiti mail na zadanu adresu, ili obavijestiti korisnika (pošiljaoca maila) da je u nemogućnosti da to uradi. Komunikacija izmeĎu servera i klijenta se odvija na slijedeći način. Server osluškuje na predviĎenom portu (port 25 je standardan po SMPT protokolu), a klijent inicira konekciju (sesiju) sa serverom, spajajući se na IP servera na zadanom portu. Nakon što server prihvati konekciju klijenta, on javlja da je spreman pozdravnom porukom. Nakon toga klijent šalje poruke serveru, koje ,zajedno sa svojim argumentima, moraju biti sadrţane u jednom redu teksta, što znači da se sve naredbe završavaju sa tzv. CRLF parom karaktera (Carriage Return Line Feed). CRLF predstavlja za prelazak u novi red i vraćanje pokazivača na početak reda. Izuzetak od ovog pravila je samo kada klijent isporučuje korisni sadrţaj maila (payload, engl.), tada je potrebno da se na kraju sadrţaja maila naĎe '.' (tačka) izmeĎu dva CRLF para („CRLF.CRLF“). Server takoĎer šalje svoje odgovore na sličan način kao i klijent. Svi odgovori koje server pošalje većinom su jednolinijski i završavaju sa CRLF. Ako server treba poslati višelinijski odgovor klijentu, on to radi na način da nakon brojčanog koda odgovora umeće znak '-' (minus) u svaki red odgovora osim u zadnji. Sva komunikacija izmeĎu servera i klijenta se mora odvijati skupom karaktera koji se nalaze u ASCII tabeli (American Standard Code for Information Interchange), dakle skupu od 127 alfanumeričkih i specijalnih znakova

17

iz američkog engleskog jezika. Kada klijent završi sa isporukom maila serveru, on prekida konekciju i sa tim se smatra da je sesija završena. 2.5.1 SMTP naredbe Kao što smo već spomenuli, SMTP naredbe su poruke koje klijent šalje serveru. Naredbe mogu doći same, ili proširene argumentima, što je i češći slučaj. Sve poruke moraju bi završene sa CRLF parom karaktera, osim u slučaju kada se radi o isporuci korisnog sadrţaja maila, kada se poruka mora završiti sa skupom karaktera „CRLF.CRLF“. Naredbe opisane u SMTP protokolu su:  EHLO ili HELO  MAIL  RCPT  DATA  RSET  VRFY  EXPN  HELP  NOOP  QUIT. 2.5.1.1 EHLO ili HELO Ove naredbe se koriste kao pozdravna poruka klijenta serveru, odnosno praksa je da se koriste za identifikaciju klijenta serveru. Obično se kao argument prosljeĎuje domensko ime klijenta, u slučaju kada klijent ne posjeduje isto, prosljeĎuje se IP adresa klijenta. Treba, meĎutim napomenuti da argument nije obavezan, i da server ne bi trebao odbiti komunikaciju sa klijentom ako ova naredba doĎe bez argumenta. Klijent bi svoju komunikaciju sa serverom trebao započeti ovom naredbom. HELO (Hello, engl.) naredba se nalazi u zastarjelom SMTP protokolu opisanom u RFC-u 821[16], dok je novija EHLO (Extended Hello) uvedena kao dodatak SMTP protokolu i danas se češće koristi. MeĎutim zbog kompatibilnosti sa starijim sistemima, svaki server mora znati prepoznati obje naredbe te adekvatno odgovoriti na njih, što znači da, generalno gledano, klijent svoju sesiju započinje slanjem jedne od ove dvije naredbe serveru. Sintaksa: EHLO naredba = „EHLO domain/IP CRLF“ HELO naredba = „HELO domain/IP CRLF“ Primjer: EHLO tfb.edu.com 250 Server greets tfb.edu.com

C: S:

18

2.5.1.2 MAIL Ovom naredbom klijent serveru označava mail adresu pošiljaoca. Naredba nikad ne moţe doći bez argumenta. Iako se uz gotovo uvijek doda i engleska riječ FROM, serveru je dovoljno da prepozna samo MAIL naredbu. Sintaksa: MAIL naredba = „MAIL FROM: CRLF“ Primjer: MAIL FROM: 250 OK

C: S:

2.5.1.3 RCPT Skraćenica od engleske riječi recipient, što znači primaoc. Ovom naredbom se serveru označuje ko je primaoc maila. Nikad ne moţe doći bez argumenta i za više primaoca se moţe izdati više puta, ali svaki put sa po jednim primaocem u argumentu. Slično kao i kod MAIL naredbe, i RCPT se obično proširuje engleskom riječi TO, meĎutim serveru treba biti dovoljno da prepozna samo RCPT naredbu. Sintaksa: RCPT naredba = „RCPT TO: Primjer: RCPT TO: 250 OK, User recognized

C: S:

2.5.1.4 DATA Sa ovom naredbom klijent govori serveru da nakon nje slijedi korisni dio maila (payload, engl.). Obično na ovu komandu server odgovara sa 354 kodom, koji daje na znanje klijentu da je spreman za prijem podataka. DATA naredbu server bi trebao odbiti ako prije toga nije izdana MAIL i RCPT naredba. Nakon primitka 354 koda od servera, klijent moţe početi sa slanjem podataka koje treba završiti sa „CRLF.CRLF“ skupom karaktera koji označavaju serveru da su svi podaci isporučeni. Tek nakon toga server odgovara sa 250 kodom. Naredba DATA se izdaje bez argumenata. Sintaksa: DATA naredba = „DATA CRLF“ Primjer: DATA 354 Start mail input; end with CRLF.CRLF
19

C: S:

2.5.1.5 RSET Ova naredba je skraćenica od engleske riječi RESET, i predstavlja poruku serveru da trenutnu mail transakciju prekine. To za posljedicu ima da server mora zanemariti sve podatke koje je do sad primio od klijenta (pošiljaoca, primaoca, payload, itd.). Naredba nema argumenata i njeno izdavanje ne označava prekid konekcije. Sintaksa: RSET naredba = „RSET CRLF“ Primjer: RSET 250 OK

C: S:

2.5.1.6 VRFY Skraćenica od engleske riječi VERIFY. Ovom naredbom klijent traţi od servera da provjeri da li moţe identificirati argument kao primaoca ili njegovu mail adresu. Znači da ova naredba uvijek dolazi sa argumentom. Sintaksa: VRFY naredba = „VRFY user@domain/user_name CRLF“ Primjer: VRFY adis 250 Adis Hodzic

C: S:

2.5.1.7 EXPN Skraćenica od EXPAND. Ovom naredbom klijent traţi od servera da provjeri da li je argument naredbe mailing lista, ako jeste da napise koji su korisnici registrirani kao primaoci te liste. Naredba uvijek mora imati argument i većinom kao rezultat server vraća višelinijski odgovor (osim u slučaju kad je samo jedan primaoc član liste). Da bi klijent mogao razlikovati ovaj višelinijski odgovor servera od običnog, svaka linija odgovora servera odmah nakon brojčanog koda sadrţi '-' (znak minus) osim zadnje linije. Sintaksa: EXPN naredba = „EXPN lista CRLF“ Primjer: EXPN vijestilista 250-Adis Hodzic 250-Amel Dzanic 250 Camil Sukic

C: S: S: S:

20

2.5.1.8 HELP Ovom naredbom klijent traţi od servera da mu pošalje neke informacije koje bi mogle biti od pomoći. Naredba moţe imati argument (na primjer drugu naredbu za koju klijent ţeli pomoć), ali i ne mora. Odgovor servera na HELP naredbu počinje brojčanim kodom 211 nakon kojeg slijedi status sistema, i/ili kodom 214 nakon kojeg slijedi poruka o pomoći. Sintaksa: HELP naredba = „HELP (naredba) CRLF“ Primjer: HELP VRFY 211 OK, VRFY is used like 'VRFY user@domain/user_name CRLF'

C: S:

2.5.1.9 NOOP Ova naredba nema efekta na bilo koju prethodno unesenu naredbu. Nema argumenta i većinom sluţi samo za testiranje (na primjer da li je konekcija sa serverom još uvijek aktivna). Sintaksa: NOOP naredba = „NOOP CRLF“ Primjer: NOOP 250 OK

C: S:

2.5.1.10 QUIT Ovom naredbom klijent govori serveru da ţeli prekinuti konekciju. Klijent treba sačekati da mu server odgovori sa 221 brojčanim kodom i tek nakon toga prekinuti konekciju sa serverom. Sa druge strane server moţe odmah nakon slanja 221 poruke prekinuti konekciju. Naredba ne dolazi sa argumentima i moţe se izdati u bilo kojem trenutku sesije. Sintaksa: QUIT naredba = „QUIT CRLF“ Primjer: QUIT 221 Server is closing connection

C: S:

21

2.5.2 SMTP odgovori Svi odgovori koje server šalje klijentu na početku imaju numerički kod koji pobliţe definira o kakvom se odgovoru radi. Neki odgovori nakon koda imaju argumente, dok drugi mogu imati običan tekst koji je koristan samo ljudima, ne i mail klijentima (prije se je mail većinom slao preko terminala kao što je na primjer telnet, nije sve bilo automatizovano kao danas). Svaki klijent mora znati prepoznati SMTP odgovore prema njihovom brojčanom kodu, te u skladu sa tim prepoznati i argumente ako ih ima. Naravno, svaka linija poruke u SMTP odgovoru mora završavati sa CRLF parom karaktera, a ako se radi o višelinijskom odgovoru, nakon brojčanog koda umeće se znak '-' u svaku liniju poruke osim u zadnju. Ispod se nalazi kompletan pregled svih numeričkih kodova odgovora, kao i njihovo značenje. 221 214 220 221 250 251 252 354 421 450 451 452 455 500 501 502 503 504 550 551 552 554 555 Status sistema, ili poruka pomoći Poruka pomoći (na primjer kako koristiti neku komandu). Ova naredba korisna samo ljudima. Server spreman Server zatvara konekciju OK, zahtijevana naredba uspješno obavljena Korisnik nije lokalni korisnik, server će pokušati forward poruke Korisnik se ne moţe provjeriti, ali server prihvata poruku i pokušati će je isporučiti Server spreman za primanje payload-a Usluga nije dostupna, zatvara se konekcija Zahtijevana akcija nije uraĎena, Mail Box primaoca nije dostupan Zahtijevana akcija prekinuta zbog lokalne greške u procesiranju Zahtijevana akcija prekinuta, nedovoljno prostora na file sistemu Server ne moţe udovoljiti parametrima Greška u sintaksi, naredba nije prepoznata Greška u sintaksi parametara ili argumenata Naredba nije implementirana Nepravilna sekvenca naredbi Parametar nije implementiran Akcija nije izvršena, Mail Box ne postoji Korisnik nije lokalni korisnik Zahtijevana akcija prekinuta, izvršavanje ove akcije bi prevazišlo prostor dodijeljen u file sistemu Transakcija nije uspjela, ili u slučaju kada se uspostavlja konekcija izmeĎu klijenta i servera označava da server nije dostupan MAIL FROM/RCPT TO parametri nisu prepoznati, ili nisu implementirani

22

2.5.3 Sekvence odgovora u odnosu na stanje sesije Slijedeći redovi donose pregled koji se odgovori mogu pojaviti u odreĎenim stanjima sesije izmeĎu klijenta i servera. Sa slovom S su označeni odgovori ako je naredba uspješno izvršena, a slovom E ako se je desila neka greška, ili naredbu nije moguće izvršiti. Sa slovom I označena je spremnost za primanje payload-a nakon naredbe DATA. KONEKCIJA USPOSTAVLJENA S: 220 E: 554 EHLO ili HELO S: 250 E: 504, 550, 502 MAIL S: E: RCPT S: E: DATA I: E: RSET S: VRFY S: E: EXPN S: E: HELP S: E: NOOP S: QUIT S: 221 250 211, 214 502, 504 250, 252 550, 500, 502, 504 250, 251, 252 550, 551, 553, 502, 504 250  podaci  S: E: 503, 554 354 250 552, 554, 451, 452, 450, 550 250, 251 550, 551, 552, 553, 450, 451, 452, 503, 455, 555 250 552, 451, 452, 550, 503, 455, 555

23

2.5.4 Dijagram toka SMTP servera Na slijedećoj slici moţe se vidjeti dijagram toka jednog SMTP servera. Dijagram je pojednostavljen i ne sadrţi specifične odgovore na sve komande klijenta. Specifični odgovori se mogu pronaći u prethodnom odjeljku, a njihova pojašnjenja u odjeljku prije njega.

Uspostavljanje konekcije
Konekcija uspješna? ODGOVORI HELO DA Primi naredbu

MAIL

NE QUIT? DA

RCPT Primi podatke

DATA

NE

RSET ODGOVORI VRFY

EXPN

HELP

Kraj sesije
NOOP

Slika 2.5: Dijagram toka SMTP servera

24

2.5.5 Primjer sesije izmeĎu SMTP servera i klijenta U prikazu ispod se moţe vidjeti komunikacija izmeĎu SMTP servera i klijenta. Kao server korišten je server programiran u sklopu praktičnog dijela ovog rada opisan u poglavlju 4. Kao klijentska aplikacija korišten je Telnet. Kreirana su dva mail računa, test1@adis.dyndns.info i test2@adis.dyndns.info. Prikazano kako izgleda kada korisnik test1 šalje mail korisniku test2. S: C: S: C: S: C: S: C: S: C: C: S: C: S: 220 Terminator SMTP server at @adis.dyndns.info ready EHLO 192.168.1.50 250 OK greets 192.168.1.50 MAIL FROM: 250 OK RCPT TO: 250 OK User recognized DATA 354 Start mail input; end wiht . Ovo je testna poruka. Test 1 250 OK Data recieved(31) QUIT 221 Server at @adis.dyndns.info closing connection

2.6 POP3 – Post Office Protocol verzija 3 U prethodnom odjeljku vidjeli smo da je zadaća SMTP protokola da primi mail i pohrani ga u svoj file sistem. MeĎutim SMTP protokol ne moţe sluţiti i za prikaz maila, pa je za tu ulogu morao biti napravljen novi protokol jednostavno nazvan POP. POP (Post Office Protocol) se prvi put spominje u dokumentu RFC 918[18] 1984. godine, meĎutim već slijedeće godine uslijedila je nova verzija POP2[19]. Nakon toga je uslijedilo nekoliko manjih dopuna protokola, a trenutna verzija POP3 objavljena je 1996. godine u dokumentu RFC 1939[20]. Glavni cilj POP3 protokola je da omogući korisnicima da na jednostavan način pristupe svojim mail računima sa udaljenih računara. POP3 ne nudi puno opcija za manipulaciju sa mailom, jedine opcije koje nudi su da se mail moţe download-ati i/ili izbrisati iz korisničkog Mail Boxa. POP3 protokol zahtijeva garantirani prijenos podataka (TCP) te inicijalno radi na portu 110 i slično kao i kod SMTP protokola, klijent i server razmjenjuju poruke koje predstavljaju naredbe (klijent) i odgovore (server). Sve poruke moraju završavati CRLF parom karaktera i takoĎer moraju biti pisane pomoću karaktera iz ASCII tabele. Za razliku od SMTP naredbi, sve POP3 naredbe su jednolinijske, a neki odgovori mogu biti višelinijski. U tom slučaju, nakon što server pošalje sve poruke koje su dio odgovora, završava slanje sa '.' (tačka) znakom izmeĎu dva CRLF para („CRLF.CRLF“). POP3 sesija u svom ţivotnom vijeku moţe prolaziti kroz više stanja. Kada se uspostavi TCP konekcija sa serverom sesija ulazi u stanje autorizacije (Authorisation state, engl.). U ovom stanju, klijent se mora identificirati serveru. Kada je klijent uspješno izvršio identifikaciju, sesija ulazi u stanje transakcije (Transaction state, engl.), u kojem zapravo i vrši glavnu interakciju sa serverom (provjera maila, označavanje pojedinih mailova za brisanje, itd.). Kada klijent izda QUIT naredbu, sesija ulazi u stanje izvršavanja (Update
25

state, engl.). U ovom stanju POP3 server obično obavi sve radnje koje je dogovorio sa klijentom u stanju transakcije, pošalje klijentu odjavnu poruku, zatvori konekciju i onda se smatra da je sesija završena. Odgovori POP3 servera su puno jednostavniji od odgovora SMTP servera, i sve odgovori imaju samo 2 oblika. Za negativan odgovor server šalje poruku „-ERR“, a pozitivan „+OK“. Ako se radi o višelinijskom odgovoru (koji moţe uslijediti samo nakon „+OK“), server ne umeće „+OK“ u svaku liniju poruke odgovora, već takvu poruku završava sa '.' kao što je to gore opisano.

2.6.1 Stanje autorizacije (Authorisation state) U ovo stanje se ulazi odmah nakon što se uspostavi konekcija klijenta sa serverom. Klijent se mora identificirati serveru ili izdati naredbu QUIT(u ovom slučaju server ne bi ušao u stanje izvršavanja nakon QUIT naredbe jer nikakve transakcije nisu ni obavljene). Ovaj protokol definiše dva načina identifikacije klijenta. Protokolom nije definisano koji način se mora koristiti, ali svaki POP3 server mora imati barem jedan način autentifikacije klijenata. U stanju autorizacije klijent moţe serveru poslati dvije naredbe (uz gore spomenutu QUIT), a to su :  USER/PASS  APOP.

2.6.1.1 USER/PASS Ove dvije naredbe su fizički odvojene, ali logički dolaze u kombinaciji. To znači da će klijent prvo morati izdati naredbu USER i nakon što je ona uspješno izvršena naredbu PASS (Password, engl.). Tek nakon što server pozitivno odgovori na naredbu PASS, klijentu je dopušten ulazak u stanje transakcije. Obje naredbe moraju doći sa argumentima koji u jednom slučaju predstavljaju korisničko ime, a u drugom lozinku klijenta. Glavni nedostatak ove vrste autorizacije je što se korisničko ime i lozinka prenose preko mreţe u obliku običnog teksta, pa se iste relativno lako moţe ukrasti i time pričiniti šteta klijentu. Sintaksa: USER naredba = „USER korisničko_ime CRLF“ PASS naredba = „PASS lozinka CRLF“ Mogući odgovori servera: +OK Name is valid -ERR User not recognized +OK Password accepted -ERR Password wrong

26

C: S: C: S:

Primjer: USER adis +OK User recognized PASS 1234 +OK Password valid

2.6.1.2 APOP APOP naredba predstavlja nadogradnju USER/PASS kombinacije naredbi. Kao argument koristi dva parametra, prvi je korisničko ime, a drugi digest (kratak prikaz, prijevod sa engl.). Digest se računa pomoću MD5 algoritma kako je navedeno u dokumentu RFC 1321[21]. Dakle pomoću ove naredbe se u jednom redu izvrši autorizacija korisnika za razliku od USER/PASS kombinacije i nakon što server izda pozitivan odgovor klijent ulazi u stanje transakcije. Prednost korištenja ovakvog načina autorizacije je povećana sigurnost. Sintaksa: APOP naredba = „APOP korisničko_ime digest CRLF“ Mogući odgovori servera: +OK User recognized -ERR Permission denied Primjer: APOP adis c4c9334bac560979e9v9892s +OK MailBox ready

C: S:

2.6.2 Stanje transakcije (Transaction State) Nakon što se je klijent uspješno identificirao serveru sesija ulazi u stanje transakcije. Klijent sada moţe izdavati bile koje naredbe predviĎene za korištenje u ovom stanju. Nakon svake naredbe server odmah šalje odgovor. Ako klijent izda naredbu QUIT dok se sesija nalazi u ovom stanju, sesija prelazi u stanje izvršavanja. Naredbe koje su validne u stanju transakcije su:  STAT  LIST  RETR  DELE  NOOP  RSET.

27

2.6.2.1 STAT Ovom naredbom klijent traţi od servera da mu prikaţe stanje korisničkog Mail Box-a. Server na ovu naredbu šalje pozitivan odgovor kojem dodaje broj poruka u Mail Box-u i veličinu tih poruka izraţenu u bajtovima (byte). Uz ovu naredbu ne ide nikakav argument. Poruke koje se označe za brisanje se ne smiju pojavljivati kao rezultat naredbe STAT. Sintaksa: STAT naredba = „STAT CRLF“ Mogući odgovori servera: +OK nn mm (gdje nn broj poruka, a mm veličina u bajtovima) Primjer: STAT +OK 2 320

C: S:

2.6.2.2 LIST Uz ovu naredbu argument je opcionalan. Ako klijent izda naredbu bez argumenta, server će poslati višelinijski odgovor. U prvom redu će se naći poruka slična odgovoru na STAT naredbu, dakle pozitivan odgovor i broj poruka zajedno sa njihovom veličinom u bajtima. Nakon toga u svakom slijedećem redu odgovora server ispisuje redni broj poruke (1 – n) i veličinu samo te poruke u bajtima. Ako klijent izda naredbu sa argumentom, a u ovom slučaju argument je redni broj poruke (1 – n), server pruţa jednolinijski pozitivan odgovor u kojem se nalazi redni broj poruke i njena veličina u bajtima. Server moţe izdati negativnu naredbu samo u slučaju ako klijent kao argument zada nepostojeći redni broj poruke (veći od n). Sintaksa: LIST naredba: „LIST [n] CRLF“ Mogući odgovori servera: +OK List follows -ERR No such message Primjer: LIST +OK 2 320 1 120 2 200 . LIST 2 +OK 2 200

C: S: S: S: S: C: S:

28

2.6.2.3 RETR Naredbom RETR klijent poručuje serveru da ţeli da mu se dostavi odreĎen mail. Argument je obavezan i on predstavlja broj poruke koju klijent ţeli da mu bude dostavljena. Sintaksa: RETR naredba = „RETR n CRLF“ Mogući odgovori servera: +OK Message follows -ERR No such message here Primjer: RETR 1 +OK 120 bytes .

C: S: S: S:

2.6.2.4 DELE Ovom naredbom klijent poručuje serveru da ţeli da se poruka čiji se redni broj nalazi u argumentu, izbriše sa servera nakon što sesija uĎe u stanje izvršavanja. Dakle, iako se poruka neće prikazati na primjer nakon izdavanja naredbe STAT, ona još uvijek postoji u file sistemu i biće izbrisana tek nakon što sesija uĎe u stanje izvršavanja. Argument je takoĎer obavezan. Sintaksa: DELE naredba = „DELE n CRLF“ Mogući odgovori servera: +OK Message deleted -ERR No such message Primjer: DELE 1 +OK Message 1 deleted

C: S:

2.6.2.5 NOOP Nakon ove naredbe, jedino što server uradi je slanje pozitivnog odgovora (slično kao i kod SMTP protokola). Sintaksa: NOOP naredba = „NOOP CRLF“ Mogući odgovori servera: +OK
29

C: S:

Primjer: NOOP +OK

2.6.2.6 RSET Ako je bilo koja mail poruka bila označena za brisanje, ovom naredbom se ta oznaka poništava. Nema argumenata. Sintaksa: RSET naredba = „RSET CRLF“ Mogući odgovori servera: +OK Reset completed Primjer: RSET +OK Reset completed

C: S:

2.6.3 Stanje izvršavanja (Update state) U ovom stanju se sesija moţe naći samo nakon QUIT naredbe u stanju transakcije. Ako se naredba QUIT izda u stanju autorizacije, server će prekinuti konekciju ali neće ući u stanje izvršavanja, a isto će se desiti ako se konekcija iz bilo kojeg razloga prekine sa strane klijenta. Nakon što sesija uĎe u stanje izvršavanja, server će sve poruke označene za brisanje zaista i fizički izbrisati iz Mail Box-a. Ne postoje naredbe koje su validne u ovom stanju, ali ćemo opisati naredbu QUIT unutar ovog odjeljka, jer je upravo ona inicijator ovog stanja. 2.6.3.1 QUIT Kao što je već rečeno, nakon ove naredbe sesija ulazi u stanje izvršavanja. Naredba nema argumenta, i server će odgovoriti pozitivno ako su sve poruke označene za brisanje uspješno izbrisane, ili ako nijedna nije označena. Negativan odgovor klijent moţe dobiti ako neke ili sve poruke nisu uspješno izbrisane. Nakon slanja odgovora klijentu server prekida konekciju. Sintaksa: QUIT naredba = „QUIT CRLF“ Mogući odgovori servera: +OK -ERR Some deleted messages not removed Primjer: QUIT +OK POP3 server at domain signing off
30

C: S:

2.6.4 Dodatne POP3 naredbe Postoje dvije opcionalne POP3 naredbe. One nisu obavezna ali je dobra praksa da se i one implementiraju. Radi se o naredbama:  TOP  UIDL.

2.6.4.1 TOP Ovom naredbom klijent traţi od servera da mu dostavi n prvih redova traţene mail poruke. Obavezno ima argument sa 2 parametra, od kojih prvi predstavlja redni broj poruke (i ne moţe se odnositi na poruku označenu za brisanje), a drugi predstavlja broj traţenih redova. Treba napomenuti da ako je poruka kraća od broja redova koje je klijent traţio, isporučuje se cijela poruka. Svaki odgovor servera je višelinijski. Naredba se moţe izdati samo u stanju transakcije. Sintaksa: TOP naredba = „TOP nn mm CRLF“ (gdje je nn redni broj poruke, a mm broj redova) Mogući odgovori servera: +OK Top of message follows -ERR No such message Primjer: Top 1 10 +OK .

C: S: S: S:

2.6.4.2 UIDL Naredbom UIDL klijent traţi od servera da mu izlista sve poruke korisnika i da svakoj od njih dodjeli jedinstveni ID. Naredba moţe imati argument koji predstavlja redni broj poruke. U slučaju da naredba nema argument server šalje višelinijski odgovor, u kojem u svakoj liniji stoji redni broj poruke nakon kojeg slijedi jedinstveni ID iste. Ako je naredba izdana sa argumentom, server šalje odgovor u jednoj liniji, opet sa rednim brojem te poruke i jedinstvenim ID-em. ID moţe sadrţavati najviše 70 alfa-numeričkih znakova i mora ostati jedinstven nezavisno od sesije u kojem je traţen za datu mail poruku. Protokol ne odreĎuje način na koji će server izračunati ID. Sintaksa: UIDL naredba: „UDIL [n] CRLF“ Mogući odgovori servera: +OK Unique-ID listing follows -ERR No such message
31

C: S: S: S: S: C: S:

Primjer: UIDL +OK 1 OSK2oksjilp20421jkkoOls 2 osLlwllwi02kln091L . UIDL 1 +OK 1 OSK2oksjilp20421jkkoOls

2.6.5 Dijagram toka POP3 servera Na slijedećoj slici je prikazan dijagram toka POP3 servera. Dijagram prvenstveno prikazuje kako se sesija izmeĎu servera i klijenta kreće kroz svoja stanja, a ne ulazi u detalje i ovisnosti naredbi o stanju. Sve naredbe i detaljni opisi o stanju se mogu pročitati u prethodnim odjeljcima.
Uspostavljanje konekcije
Konekcija uspješna? DA ODGOVORI Primi naredbe

Stanje autorizacije NE Autorizacija uspješna DA Stanje transakcije NE

NE

QUIT? DA Stanje izvršavanja

ODGOVORI

Kraj sesije

Slika 2.6: Dijagram stanja POP3 servera
32

2.6.6 Primjer sesije izmeĎu POP3 servera i klijenta Slično kao i u primjeru 2.5.5, i ovdje je za server korišten program opisan u poglavlju 4, a kao klijentska aplikacija posluţio je Telnet. Ovdje je prikazano kako korisnik sa korisničkim imenom test2 pristupa svom Mail Box-u i čita jedan mail. S: C: S: C: S: C: S: C: S: S: S: S: S: S: S: C: S: S: S: C: S: +OK POP3 server at Terminator signing off USER test2 +OK user recognized PASS test +OK user mailbox ready STAT +OK 5 2623 LIST +OK 5 2623 1 407 2 2162 30 4 23 5 31 . RETR 5 +OK 5 31 Ovo je testna poruka. Test 1 QUIT +OK POP3 server at Terminator signing off

2.7 IMAP – Internet Message Access Protocol U skupu protokola za slanje i čitanje mail poruka, treba spomenuti i protokol IMAP koji se moţe pronaći u dokumentu RFC 3501 [22]. Pregled ovog protokola će biti skraćen jer se radi o najsloţenijem i najmodernijem mail protokolu, te bi njegov kompletan opis zauzeo veći broj stranica nego što je dokumentom ove vrste predviĎeno. Treba spomenuti da IMAP, slično kao i POP3 protokol sluţi prvenstveno za pristupanje mail porukama. IMAP dozvoljava klijentu da pristupa i manipulira mail porukama na serveru na način koji je funkcionalno jednak radu sa datotekama na disku. Protokol dopušta operacije za kreiranje, brisanje i preimenovanje Mail Box-a. TakoĎer dopušta provjeravanje novih poruka, brisanje poruka, pretraţivanje, selektivno preuzimanje poruka ili dijelova poruka, itd. Komunikacija izmeĎu klijenta i servera se odvija na sličan princip kao i kod SMTP i POP3 protokola, razmjenom tekstualnih poruka. IMAP implementira 23 klijentske naredbe i isti toliki broj serverskih odgovora, te slično kao i POP3 protokol, sesiju dijeli na nekoliko stanja. Treba još spomenuti da se IMAP protokol najčešće koristi kod web mail sistema.

33

2.8 MIME – Multipurpose Internet Mail Extensions Iako je SMTP sasvim zadovoljavao potrebe prijenosa maila u vrijeme kad je on i nastao (rane osamdesete godine), njegovo ograničenje na skup karaktera iz ASCII tabele ubrzo počinje predstavljati značajan problem. Moţe se reći da je problem prisutan već od samog početka jer korisnici koji su htjeli napisati mail slovima koji se ne nalaze u engleskom jeziku jednostavno to nisu mogli uraditi, ali kad se uzme u obzir veoma malenu rasprostranjenost interneta u to vrijeme, te primarno korištenje istog većinom u naučnim krugovima, takve stvari su se još mogle tolerisati. Ekspanzijom interneta na široki krug ljudi koji se javlja uglavnom u devedesetim godinama, SMTP ograničenja postaju značajan problem. Najveći nedostatak bio je nemogućnost slanja binarnih objekata (datoteka, slika, video i audio zapisa, itd.) jer se svi bitovi nekog objekta jednostavno ne mogu predstaviti pomoću 127 znakova iz ASCII tabele. Iz tog razloga, a i zbog omogućavanja korisnicima da u svojim mail porukama sadrţaj pišu bez ograničenja na slova iz engleskog alfabeta, pristupa se rješavanju problema čije je rezultat nastanak MIME formata mail poruka. Akutelna verzija MIME-a se moţe pročitati u skupu od 5 RFC dokumenta a to su, RFC 2045[23], RFC 2046[24], RFC 2047[25], RFC 2048[26] i RFC 2049[27]. Treba napomenuti da MIME nije zamjena za SMTP, MIME stupa na scenu kada klijent formatira sadrţaj mail poruke (payload) na način da se prevaziĎu ograničenja predstavljena SMTP protokolom, uz korištenje znakova iz ASCII tabele. Iako se pomoću ovog dodatnog formatiranja mail poruka stvara efektivno veći sadrţaj (oko 33%), ovako je učinjeno zbog zadrţavanja kompatibilnosti sa starijim mail sistemima. Danas je MIME postao de-facto standard i vrlo teško će se pronaći mail poruka a da ona nije formatirana pomoću MIME pravila. Pošto je MIME format vrlo opseţan i u ovom radu je nemoguće osvrnuti se na njegove specifičnosti, u slijedećim odjeljcima ću prikazati najvaţnija MIME zaglavlja (header, engl.) i kodiranja . 2.8.1 MIME zaglavlja MIME zaglavlja su polja kojima se opisuje sadrţaj koji slijedi. Obično su oblika atribut:vrijednost (atribute:value). Treba napomenuti da MIME dozvoljava korisnicima kreiranje vlastitih zaglavlja (iako ne ohrabruje takvu radnju), uz uslov da ta zaglavlja uvijek počinju sa velikim ili malim slovom „X“. Takva zaglavlja ne bi trebala uticati na sam sadrţaj mail poruke, dakle mail poruku treba biti u mogućnosti ispravno dekodirati i bez poznavanja korisnički definiranih zaglavlja, pa su i server i klijent slobodni da ih ignoriraju. Najvaţnija MIME zaglavlja su:  MIME-Version  Content-ID  Content-Type  Content-Transfer-Encoding.

34

2.8.1.1 MIME-Version MIME-Version zaglavlje označava da je poruka formatirana pomoću MIME-a. Iako je MIME doţivio neke izmjene od svog prvog pojavljivanja, zadrţana je osobina da se uvijek kao vrijednost zaglavlja stavlja broj 1. Treba napomenuti da vrijednosti zaglavlja „1.0“ i „1“ imaju isto značenje. Primjer: MIME-Version: 1.0

2.8.1.2 Content-ID Ovo zaglavlje prvenstveno sluţi kod Multipart podtipova Content-Type zaglavlja. Sa njim se jedinstveno označavaju pojedini dijelovi poruke. MIME ne definiše na koji način treba izračunati vrijednost ovog zaglavlja, meĎutim on bi trebao biti globalno jedinstven za svaki dio poruke u kojem se koristi. Iz tog razloga često se na kraj dodaje znak „@“ i domena servera, a onda server vodi računa da prvi dio vrijednosti zaglavlja ima jedinstvenu vrijednost unutar njegove domene. Vrijednost zaglavlja se stavlja unutar zagrada „“. Primjer: Content-ID:

2.8.1.3 Content-Type Cilj ovog zaglavlja je da dovoljno dobro opiše podatke koji se nalaze iza njega, tako da korisnik moţe prepoznati vrstu podataka i postupiti u skladu sa tim. Moţe sadrţavati više parova atribut:vrijednost, čiji poredak nije vaţan, ali su svi odvojeni znakom ';' (tačka-zarez). Kompletan pregled svih propisanih vrijednosti koje ovo zaglavlje moţe imati se moţe vidjeti u dodatku B. Ovdje još treba pojasniti moţda i najčešće korišteni atribut, a to je boundary (graničnik, slobodan prijevod sa engl.). Boundary se koristi ako se kao vrijednost zaglavlja upotrijebi multipart vrijednost, kojim se označava da ta mail poruka ima više dijelova (na primjer više datoteka). Pošto svaki od tih dijelova moţe imati parove atribut:vrijednost koji vaţe samo za njega, potrebno je više tih dijelova na neki način razgraničiti tako da čitač mail poruke zna kako postupiti sa kojim dijelom. Boundary mora biti jedinstven unutar te mail poruke. Početak dijela ograničenog boundary vrijednošću uvijek ima dva znaka '-' (minus) ispred same vrijednosti, a kraj tog dijela je označen sa dva znaka '-' (minus) ispred i iza vrijednosti. U praksi se gotovo uvijek susreće Boundary jer gotovo svaki mail klijent kreira više verzija sadrţaja, tako da bi drugi klijent na kojem se čita mail mogao odabrati njemu najpogodniji za prikazati, a to nam donosi poruku u više dijelova.

35

Primjer: Content-Type: multipart/alternative; boundary=0015174935e622a767049c7714a5 --0015174935e622a767049c7714a5 Content-Type: text/plain; charset=ISO-8859-1 --0015174935e622a767049c7714a5

2.8.1.4 Content-Transfer-Encoding Pomoću ovog zaglavlja se govori koja je vrsta kodiranja korištena u tom dijelu mail poruke. Kao što je već u uvodnom dijelu ovog odjeljka pojašnjeno, kodiranje je potrebno iz dva razloga: 1. Ako korisnik koristi znakove koji se ne nalaze u engleskom alfabetu (na primjer bosanski, japanski itd.) 2. Ako korisnik šalje binarni objekt jer njih nije moguće prikazati pomoću znakova iz ASCII tabele. Imamo 3 vrste kodiranja:  7bit kodiranje  Quoted-Printable kodiranje  Base64 kodiranje. 7bit-no kodiranje je podrazumijevana (default, engl.) vrijednost i ako se ovo zaglavlje ne koristi, klijent treba postupiti kao da se radi o kodiranju ove vrste. Ovo kodiranje zapravo govori da je kompletan sadrţaj napisan u pomoću ASCII znakova i da nije potrebno dodatno pretvaranje, već da se klijentu isporuči u obliku kakvom je i primljen.

2.8.1.4.1 Quoted-Printable kodiranje Quoted-Printable kodiranje se većinom koristi kod kodiranja teksta u kojem se ne nalazi puno ne-ASCII znakova, dakle teksta pisanog znakovima koji se ne nalaze u engleskom jeziku. Tekst kodiran na ovaj način zauzima manje prostora neko tekst kodiran Base64 kodom, i čak je i prilično čitljiv ako ga čita korisnik na klijentu koji nije u stanju dekodirati QP. Kodiranje svih znakova koji se ne nalaze u ASCII tabeli vrši se pomoću tri karaktera. Prvi je znak '=' (jednako) nakon kojeg slijede dvije heksadecimalne cifre (0 – 9 i od A – F) koje označavaju brojčanu vrijednost mjesta znaka koji se ţeli kodirati. Treba napomenuti da QP kodiranje i dekodiranje vrši uz pomoć atributa charset koji se moţe pronaći unutar Content-Type zaglavlja. Primjer: Original: Ja sam Adis Hodžić QP kod: Ja sam Adis Hod=9Ei=E6

36

2.8.1.4.2 Base64 kodiranje Za razliku od Quoted-Printable kodiranja, Base64 se većinom koristi za kodiranje binarnih objekata (datoteka). Iako ga je moguće koristiti i za kodiranje teksta, to nije praksa jer pomoću ovog kodiranja sadrţaj efektivno naraste za nekih 30%. Base64 kodiranje je opisano u dokumentu RFC 4648[28]. Base64 kodiranje je dobilo takvo ime jer sav binarni sadrţaj pokušava prikazati pomoću 64 znaka, koji se mogu pročitati u tabeli 2.2: Tabela 2.2: Base64 znakovi [28]
Vrijednost 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Znak A B C D E F G H I J K L M N O P Vrijednost 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Znak Q R S T U V W X Y Z a b c d e f Vrijednost 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 Znak g h i j k l m n o p q r s t u v Vrijednost 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 Znak w x y z 0 1 2 3 4 5 6 7 8 9 + /

Base64 radi na principu da niz bitova dijeli na grupe od po 24 bita, koje opet dijeli na grupo po 6 bitova (6 bitova moţe činiti najviše 64 različite vrijednosti) i umjesto brojčane vrijednosti te grupe bitova, umetne ekvivalentni znak iz tabele 2.2. Pošto svi znakovi koji se nalaze u tabeli 2.2 pripadaju ASCII tabeli znakova, na ovaj način se bilo koji niz bitova moţe predstaviti pomoću ASCII znakova i uspješno poslati pomoću SMTP protokola. Slijedi primjer kako se skup znakova „TFB“ kodira pomoću Base64 koda.

Tekst T F B 84 70 66 ASCII 0 1 0 1 0 1 0 0 0 1 0 0 0 1 1 0 0 1 0 0 0 0 1 0 Binarno 21 4 25 2 B64 Vrijednost V E Z C B64 Znak Slika 2.7: Primjer kodiranja pomoću Base64 algoritma

37

Na slici 2.7 prvo su karakteri „TFB“ pretvoreni u binarnu vrijednost pomoću ASCII tabele znakova a zatim je taj binarni objekt, u skladu sa Base64 pravilima kodiranja, pretvoren u Base64 kod. Moţe se primijetiti da na ovaj način raste efektivna veličina sadrţaja, meĎutim Base64 nam omogućava da bilo koji binarni objekt kodiramo i pošaljemo pomoću SMTP protokola, ili isti dohvatimo pomoću POP3 protokola. Rekli smo da Base64 inicijalno dijeli niz bitova na grupe po 24, meĎutim šta ako na kraju niza nije moguće napraviti grupu od 24 bita? Onda se radi poravnanje (padding, engl.) u kojem se nizu dodaju bitovi sa vrijednošću 0 sve dok se ne kreira zadnja grupa od 24 bita. Takve grupe bitova se označavaju sa znakom '=' (jednako), i kad klijent naiĎe na znak '=' na kraju niza bitova, on moţe smatrati da je pročitao kompletan sadrţaj i onda ga dekodirati.

38

3. SIGURNOST MAILA U prethodnom poglavlju smo mogli vidjeti koje sve protokole jedan moderan mail server mora sadrţavati, meĎutim sad dolazimo do dijela koji nije uslovljen nijednim standardom, a ipak predstavlja veoma bitnu stvar iz perspektive korisnika maila. Nijedan korisnik ne ţeli da mu se neovlašteno čitaju njegove mail poruke, a isto tako ne ţeli ni da svakodnevno bude zatrpan stotinama SPAM poruka. Nijedan od gore spomenutih protokola se ne bavi sigurnosti, osim POP3 protokola, čije su sigurnosne postavke, blago rečeno, vrlo slabe i prilično lako se mogu zaobići. Iako nijedna sigurnosna opcija nije uslovljena standardima i protokolima vezanim za rad mail servera, praksa je donijela nekoliko rješenja. Ta rješenje su se kretala u dva smjera, jedan je bio okrenut borbi protiv neovlaštenog čitanja mail poruka, a drugi u borbi protiv SPAM-a. Oba fronta su iznjedrila nekoliko različitih rješenja, koja se problem bave svaka na svoj način. TakoĎer treba spomenuti da moderni mail serveri implementiraju barem jednu od sigurnosnih opcija, a vrlo često se radi o više njih, i jednostavno odbijaju konekcije servera koji ne poštuju njihove sigurnosne postavke. Ovakav stav je u konfliktu sa standardom (koji trenutno nigdje ne specificira obaveznu upotrebu bilo koje vrste sigurnosti), ali se je moralo nešto učiniti po tom pitanju jer broj neovlaštenih upada na tuĎe mail račune, a prvenstveno broj SPAM poruka nezadrţivo rastao. Sigurnost mail servera se prema tipu sigurnosti, moţe podijeliti na dvije grupe:  Sigurnost prilikom ostvarivanje konekcije klijenta na server,  Sigurnost unutar samog maila. U slijedećim odjeljcima slijedi pregled osnovnih načina podizanja sigurnosnog nivoa mail servera. Pregled sadrţi kratak opis i način funkcioniranja pojedinih sigurnosnih opcija, uz reference na kojima se moţe pročitati više o svakoj. Pregled je morao biti skraćen jer bi detaljan opis svih osobina pojedinog protokola zahtijevao izradu dokumenta daleko većeg obima nego je to predviĎeno sa ovu vrstu rada. 3.1 Sigurnost prilikom ostvarivanja konekcije klijenta na server Kao što i samo ime kaţe, radi se o sigurnosnim postavkama koje trebaju djelovati prilikom ostvarivanja konekcije klijenta na server. U ovom slučaju će server, ako klijent ne zadovolji sigurnosne postavke, većinom prihvatiti konekciju i klijentu poslati odgovor uz objašnjenje razloga nedopuštanja daljnje interakcije sa serverom, i onda prekinuti konekciju. Ovaj postupak nije standardiziran i dosta ovisi o implementaciji servera. Sigurnosne postavke koje koriste u ovom tipu sigurnosti su namijenjene borbi protiv SPAM-a. Najčešće upotrebljavane sigurnosne opcije su:  Blacklist  SSL i TLS  SPF.

39

3.1.1 Blacklist Blacklist, ili često se još zove i DNSBL (DNS based BlackList), ja vjerovatno, uz SSL, najčešće korišteni način borbe protiv SPAM-a. Blacklist je najčešće obična tekstualna datoteka u kojoj se nalaze IP adrese zajedno sa svojom registriranom domenom. Blacklist-e odrţava jako puno meĎusobno nezavisnih grupa, i nije rijedak slučaj da pojedini serveri vrše provjere na nekoliko stotina Blacklist-a prije nego što dopuste interakciju klijentu. Većina tih grupa dopušta korištenje svojih Blacklist-a na slobodnoj osnovi, dok neke druge naplaćuju takvu uslugu. Spisak nekih Blacklist-a moţete provjeriti pomoću web stranice MxToolBox[29]. Server provjerava Blacklist-e pomoću IP adrese klijenta. Naime, server šalje upit Blacklist-i koju ţeli kontaktirati sa IP-om klijenta, i kao rezultat dobija poruku u kojoj se navodi stanje zadane IP adrese. Većinom se radi o 3 stanja:  WhiteList – IP je pouzdan (trusted, engl.)  BlackList – IP nije pouzdan, treba odbaciti komunikaciju sa njim  YellowList – Status IP-a nije moguće utvrditi, nastavak na vlastitu odgovornost. Serveri većinom odbijaju suradnju sa IP adresama koje su označene kao Blacklist ili Yellowlist. Na neku blacklistu server prijavljuju administratori drugih servera, ako primijete da sa njega dolazi veća količina SPAM-a. Sa Blacklist-e server moţe skinuti samo administrator tog servera. Tačan postupak ovisi od grupe do grupe, ali većinom se sastoji od dokazivanja vlasništva IP adrese i domene na kojima se nalazi mail server.

3.1.2 SSL – Secure Socket Layer i TLS – Transport Layer Security SSL je način enkripcije same TCP konekcije (nije moguće koristiti SSL sa UDP-om), što znači da su svi podaci koji se razmjenjuju tokom trajanja konekcije kriptirani. SSL i TLS su zapravo dvije iste stvari, SSL je od svoje prvobitne verzije 1.0 doţivio dvije veće izmjene (SSL 2.0 i SSL 3.0), nakon toga uslijedile su još tri izmjene SSL protokola, ali sad pod novim nazivom, tako da je SSL 3.1 postao TLS 1.0. Trenutno aktuelna verzija je TLS 1.2 (što je ekvivalent SSL 3.3) i moţe se pročitati u dokumentu RFC 5264[30]. TLS funkcionira na principu predstavljanja drugoj strani u komunikaciji pomoću certifikata. Svaki sudionik komunikacije kreira vlastiti certifikat koji se ovjerava od ovlaštene treće strane (ovjeravanje certifikata je na komercijalnoj osnovi). Nakon što dva sudionika komunikacije uspostave konekciju i razmijene certifikate, kontaktira se treća strana (kod koje je certifikat ovjeren) i provjerava autentičnost sudionika. Slikom se to moţe prikazati kao na slici 3.1.

40

Zahtijev za uspost avu ko

nekcije

Konekcija odobrena

Klijent

Slanje certifikata

Server

Pro vj

era

OK
Certifikat OK
Nastavak komunika cije
CA – Certificate Authenticator

Slika 3.1: Šematski prikaz uspostavljanja TLS konekcije Ovdje neću ulaziti u detalje kreiranja certifikata, njihovog ovjeravanja i provjeravanja (o navedenom se moţe više naći u gore spomenutom RFC dokumentu), iz perspektive mail servera, ovdje je dovoljno znati da uspostavom TLS konekcije server moţe vjerodostojno autentificirati klijenta te mu odobriti daljnju suradnju. Uz provjere Blacklist-a, ovo je najčešći način povećavanja sigurnosti servera, i takoĎer kao i Blacklist-e koristi se prvenstveno u borbi protiv SPAM-a.

3.1.3 SPF – Sender Policy Framework Posljednji popularni oblik zaštite servera je SPF. SPF projekt je zasnovan na volonterskoj osnovi i u svojoj osnovi jako je sličan principu funkcioniranja Blacklist-a. Blacklist-e u svom radu se oslanjaju na obične tekstualne datoteke, dok SPF kreira novi tip RR upita u DNS-u. Vlasnik MX i A tipa domene, moţe kreirati SPF zapis, koji se kasnije isporučuje kao rezultat DNS upita. Upravo zbog smještanja unutar DNS-a, SPF je i postao prilično popularan u veoma kratkom vremenu. Puno je lakše provjeravati DNS bazu, nego stotine Blacklist-a, od kojih svaka moţe imati svoja pravila postavljanja upita i dobivanja rezultata. Više o SPF-u se moţe pročitati na njihovim web stranicama[31].

41

3.2 Sigurnost unutar mail poruke U prethodnom odjeljku mogli smo vidjeti na koji način serveri obezbjeĎuju jednu vrstu sigurnosti koja prvenstveno sluţi zaštiti od SPAM poruka, a u ovom odjeljku ću opisati na koji način se moţe osigurati mehanizam za zaštitu korisničke privatnosti. Ovakva vrsta zaštite obično podrazumijeva voĎenje računa o samom sadrţaju maila, odnosno, sadrţaj maila je kodiran nekim ključem kojeg zna samo korisnik ili druga ovlaštena lica. To znači da ako se takav mail presretne, njegov sadrţaj će biti praktički nerazumljiv bilo kojoj osobi koja nema ključa kojim je isti kodiran. Dalje ću obraditi 3 načina zaštite maila:  PEM  S/MIME  OpenPGP.

3.2.1 PEM – Privacy Enhanced Mail PEM je prvi pokušaj unapreĎivanja sigurnosti maila. Javlja se početkom devedesetih godina i oslanja se kriptografiju pomoću javnog ključa. Ovaj način kriptografije podrazumijeva da korisnici kreiraju javne (public) i privatne (ključeve). Privatni ključevi su sluţili prvenstveno za enkripciju maila, dok se public ključ slao drugim korisnicima koji su onda mogli isti mail dekriptirati (sličan princip kao i kod TLS certifikata). Glavni nedostatak ovog protokola je bio što on sam nije definirao kojim tačno načinom će podaci biti kriptirani ili dekriptirani, i iako je doţivio status standarda od strane IETF-a, nikad nije masovno upotrjebljavan te je prilično brzo pao u zaborav. Bilo je pokušaja da se napravi infrastruktura za razmjenu i provjeru ključeva, meĎutim takvi pokušaji su došli prekasno, i niko nije uspio napraviti komercijalno isplativu i dovoljno popularnu infrastrukturu. Još kad je MIME stekao svoju popularnost, a PEM nije podrţavao MIME zaglavlja, PEM biva konačno napušten. Ovdje se spominje samo zbog toga što je na osnovu PEM-a nastao OpenPGP o kojem će biti riječi kasnije.

3.2.2 S/MIME – Secure/MIME Trenutno aktuelna verzija S/MIME protokola se moţe pronaći u dokumentu RFC 3851[32]. Osnovne stvari koje S/MIME pruţa su: autentifikacija korisnika (pomoću digitalnog potpisa) i enkripcija podataka. Da bi S/MIME mail poruke mogle neometano prolaziti kroz SMTP servere, dodano je novo zaglavlje MIME, a to je multipart/signed, koji se koristi da se označi digitalni potpis korisnika, a za enkripciju se oslanja na svoj mehanizam koji se oslanja na PKCS#7[33] (Public-Key Cryptografy Standard). Svi multipart/signed atributi moraju imati 3 parametra, a to su boundary, protocol i micalg. Boundary ima isti način upotrebe kao i Boundary opisan u poglavlju 2.7, protocol označava tip MIME digitalnog potpisa, a micalg predstavlja algoritam kojim je kreiran digitalni potpis. Kao algoritam za kreiranje se najčešće koristi SHA1[34] algoritam ili MD5[21] algoritam (više o istima se moţe pročitati na priloţenim linkovima). Treba još napomenuti da sav sadrţaj kriptiran nekim od spomenutih algoritama mora proći kroz Base64 kodiranje da bi bio kompatibilan sa SMTP protokolom. Kada klijent primi
42

mail poruku prvo će morati dekodirati poruku (Base64), čitač maila moţe pristupiti dekodiranju same S/MIME poruke. Kao što vidimo S/MIME obezbjeĎuje prolazak mail poruke kroz mail sistem uz prijenos odreĎenih informacija, meĎutim S/MIME se ne bavi dekripcijom poruka, takve stvari su ostavljene na izbor korisniku. Slijedi primjer S/MIME poruke. Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21"; protocol="application/pkcs7-signature" ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBw GgggL … DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4w LAIUM/mG f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21—

3.2.3 OpenPGP – Open Pretty Good Privacy PGP je program čija je licenca u vlasništvu Philip Zimmermann-a, koji je ujedno i tvorac programa. PGP sluţi za enkripciju i dekripciju podataka i zanimljivo je da je autor programa bio čak i krivično gonjen od vlade SAD-a, jer je ovim programom vrlo jednostavno omogućena enkripcija praktički bilo svega čiju je zaštitu vrlo teško (gotovo nemoguće) probiti(a znamo kako vlade ne vole da se podaci kriju od njih). Na osnovu originalnog PGP algoritma, nastaje OpenPGP (koji praktički ne donosi ništa novo osim licence za slobodno korištenje) te se sigurnost maila unaprijeĎena korištenjem ovog algoritma opisuje u dokumentu RFC 3156[35]. Kao i S/MIME i OpenPGP koristi multipart/signed atribut u MIME zaglavlju, ali njemu dodaje još i multipart/encrypted atribut. Multipart/encrypted atribut uvijek dolazi sa dvije vrijednosti, boundary i protocol. Protocol vrijednost označava tip digitalnog potpisa. OpenPGP uvijek dijeli mail poruku na dva dijela. U prvom dijelu poruke dolaze kontrolne informacije koje će pomoći klijentu u radu sa OpenPGP algoritmom, obično su to podaci o verziji i slično, dok u drugom dijelu (koji je uvijek application/octet-stream) dolazi sadrţaj maila. Slično kao i kod S/MIME-a, kriptirani sadrţaj se kodira Base64 algoritmom, isti je i postupak dekodiranja OpenPGP poruke. OpenPGP i S/MIME se mogu kombinirati, što donosi još veću sigurnost, meĎutim praksa je da je dovoljna enkripcija samo jednim od ova dva postupka. Slijedi primjer OpenPGP MIME mail poruke. Content-Type: multipart/encrypted; boundary=foo;
43

protocol="application/pgp-encrypted" --foo Content-Type: application/pgp-encrypted Version: 1 --foo Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= =zzaA -----END PGP MESSAGE------foo--

44

4. IMPLEMENTACIJA MAIL SERVERA SA PROTOKOLIMA SMTP I POP3 U JAVA PROGRAMSKOM JEZIKU U ovom poglavlju će biti opisana izrada aplikacije „Mail server“ korištenjem JAVA programskog jezika. Cilj rada je demonstracija inţinjerskog postupka (doduše u manjem obliku), a to je izrada proizvoda na osnovu postojećih naučnih saznanja. U aplikaciji su implementirani SMTP i POP3 protokoli, administracija korisnika maila, a kao file sistem maila korištena je baza podataka na MySQL Community Server-u verzije 5.5.9[36]. Kompletna aplikacija je uraĎena u NetBeans[37] IDE verzije 6.9.1, u JDK[38]-u (Java Development Kit) verzije 1.6.0_22 i za uspješno pokretanje treba imati instaliran JRE[39] (Jave Runtime Environment) verzije 6 (iako bi aplikacija trebala ispravno raditi sa svim verzijama JRE iznad 4). Primjena aplikacije moţe biti zaista široka jer ona potpuno funkcionalno obavlja posao mail servera. Aplikacija trenutno ima ograničenja jer nisu programirani sigurnosni mehanizmi opisani u prošlim odjeljcima iz jednostavnog razloga nedostatka financijskih sredstava koji su potrebni za implementiranje istih. Više o ovoj problematici biće u posebnom odjeljku.      Aplikacija ima slijedeće opcije: Pokretanje i zaustavljanje SMTP servera Pokretanje i zaustavljanje POP3 servera Pregled trenutne komunikacije izmeĎu SMTP servera i klijenta Pregled trenutne komunikacije izmeĎu POP3 servera i klijenta Administracija korisnika (dodavanje novog, izmjene postojećih i brisanje).

Pored ovih opcija „Mail server“ omogućuje podešavanja servera pomoću male datoteke sa opcijama (settings.txt) i kreira log datoteke u kojima se nalazi pregled komunikacije SMTP i POP3 servera (odvojeno) po datumu. O svim osobinama biće više riječi u narednim odjeljcima. 4.1 Model baze podataka Model baze podataka je vrlo jednostavan, ali sluţi svrsi. Sastoji se od 3 tabele, a to su folder, user i message. ER model se moţe vidjeti na slici ispod:

Slika 4.1: ER model baze podataka

45

 Tabela folder sadrţi atribute: idFolder (primarni ključ), FolderName.  Tabela user sadrţi atribute: idUser (primarni ključ), Name, LastName, User_Name, Password, maxMailBoxSize, currentMailBoxSize, mailBoxLock.  Tabela message sadrţi atribute: idMessage (primarni ključ), From, To, payLoad, deleteMessage, messageHash, idUser (strani ključ), idFolder (strani ključ). Moţda je najzanimljivije primijetiti da je payLoad u tabeli message stavljen kao BLOB (Binary Large OBject) iako se sve poruke izmeĎu klijenta i servera razmjenjuju u tekstualnom obliku. Ovo je učinjeno radi podizanja performansi servera, jer tekstualni objekti (u JAVA-i tipa String) zauzimaju puno više memorije i zahtijevaju puno više procesorskog vremena nego niz BLOB (u JAVA-i tipa byte[ ]). Ovim potezom su višestruko povećane performanse servera. SQL skripta za kreiranje inicijalne baze podataka nalazi se u dodatku C.

4.2 Klasni dijagram aplikacije Klasni dijagram sluţi za opis tipova objekata korištenih u izradi aplikacije te vrste veza koje postoje meĎu njima. Aplikacija ima ukupno 10 klasa razvrstanih u 3 paketa, a to su:  MySQLUtil  Folder  Message  User  POPConnection  SMTPConnection  POPWorker  SMTPWorker  updateQuota  MainGUI.

46

Na slijedećoj slici se moţe vidjeti klasni dijagram aplikacije:

Slika 4.2: Klasni dijagram aplikacije

Klasa MySQLUtil sadrţi parametre koji omogućuju konekciju aplikacije sa bazom podataka. Ne sadrţi metode.

Slika 4.3: Klasa MySQLUtil

47

Klasa Folder predstavlja presliku MySQL tabele folder u JAVA-i. Sadrţi uobičajene Get i Set metode.

Slika 4.4: Klasa Folder Klasa User predstavlja presliku MySQL tabele user u JAVA-i. Pored uobičajenih Get i Set metoda sadrţi još slijedeće metode: - User getUserByUserName(String user) – metoda kojom se provjerava postojanje korisnika sa imenom user - boolean isUserQuotaAvailable(int payLoadSizeInBytes, int idUser) – provjerava da li korisnik ima dovoljno prostora za prihvaćanje mail poruke - void calculateUserQuota(int id) – izračunava kvotu korisnika - ArrayList getUserByNameAndUserName(String name, String userName) – pretraţuje korisnike po imenu i korisničkom imenu - boolean deleteUser(int id) – briše korisnika sa odreĎenim id - boolean updateUser() – aţurira korisnika - boolean insertUser() – kreira novog korisnika - boolean updateAllMaxMailBoxSize(int maxMailBoxSize) – dodjeljuje novu kvotu svim korisnicima - ArrayList getAllUser() – vraća sve postojeće korisnike

Slika 4.5: Klasa User

Klasa Message predstavlja presliku MySQL tabele message u JAVA-i. Pored uobičajenih Get i Set metoda ova klasa sadrţi još slijedeće metode: - boolean saveMessage() – sprema mail poruku u bazu - ArrayList getMessagesWithoutPayload(int idUser) – dohvaća sve mail poruke odreĎenog korisnika ali bez payload-a - byte[] getMessagePayload(int idMessage) – dohvaća payload odreĎene poruke - boolean deleteMessage(int idMessage) – briše mail poruku

48

Slika 4.6: Klasa Message Klasa POPConnection implementira Runnable interfejs i predstavlja jednu nit (thread, engl.) u kojoj se izvršava logika vezana za POP3 protokol. Svakom klijentu koji se konektuje na server će biti alocirana nova nit kako ne bi došlo do blokade. Klasa sadrţi slijedeće metode: - void respond(String response, Socket socket) – metoda kojom se šalje odgovor klijentu - void sendData(byte[] data, Socket socket) – metoda kojom se šalje payload klijentu - void acceptCommandFromClient(BufferedReader fromClient, Socket socket) – metoda kojom se prima naredba od klijenta - void createFiles() – metoda kojom se kreira log datoteka - void saveToLogFile(String message) – metoda kojom se spremaju podaci u log datoteku - void setFlags() - metoda kojom se resetiraju stanja zastavica

Slika 4.7: Klasa POPConection

49

Klasa SMTPConnection slično kao i POPConnection implementira Runnable interfejs i predstavlja jednu nit u kojoj se izvršava logika vezana za SMTP protokol. Svakom klijentu koji se konektuje na server alocira se nova nit kako ne bi došlo do blokade. Klasa sadrţi slijedeće metode: - void respond(String response, Socket socket) – metoda kojom se šalje odgovor klijentu - boolean acceptMailData(BufferedReader fromClient, Socket socket) – metoda kojom se prima payload od klijenta - void acceptCommandFromClient(BufferedReader fromClient, Socket socket) – metoda kojom se prima naredba od klijenta - void createFiles() – metoda kojom se kreira log datoteka - void saveToLogFile(String message) – metoda kojom se spremaju podaci u log datoteku - void setFlags() - metoda kojom se resetiraju stanja zastavica

Slika 4.8: Klasa SMTPConnection Klasa POPWorker nasljeĎuje klasu SwingWorker i sluţi za omogućavanje više niti u Swing interfejsu. Ova klasa kreira objekat klase POPConnection. Sadrţi uobičajene Get i Set metode.

Slika 4.9: Klasa POPWorker

50

Klasa SMTPWorker ima istu ulogu kao i prethodna klasa. Dakle nasljeĎuje klasu SwingWorker i glavna joj je uloga omogućavanje više niti u Swing interfejsu. Kreira objekat klase SMTPConnection. Sadrţi uobičajene Get i Set metode.

Slika 4.10: Klasa SMTPWorker Klasa updateQouta nasljeĎuje klasu SwingWorker. Njena glavna uloga je da kreira nit koja će svakih 24h provjeriti kvote svih korisnika, i poslati obavijest onima kojima je ostalo manje od 10% prostora u Mail Box-u. Obavijest se šalje u obliku mail poruke na korisnički račun. Ne sadrţi metode.

Slika 4.11: Klasa updateQuota Klasa MainGUI predstavlja izvršnu klasu ove aplikacije, što znači da iz ove klase kreće izvoĎenje programa. U njoj je smješten GUI (Graphical User Interface) raĎen u Swing biblioteci. Klasa nasljeĎuje JFrame klasu i ima slijedeće metode: - void setLAF() – postavlja izgled aplikacije - readSettings() – čita podatke iz settings.txt datoteke na osnovu kojih postavlja parametre servera - void updateSMTPServerStatus() – prikazuje da li je SMTP server pokrenut ili ne - void updatePOPServerStatus() – prikazuje da li je POP3 server pokrenut ili ne - void enableSMTPButtons() – omogućuje/onemogućuje dugme (button, engl.) za pokretanje i gašenje SMTP servera - void enablePOPButtons() - omogućuje/onemogućuje dugme (button, engl.) za pokretanje i gašenje POP3 servera - void updateUserJlist() – osvjeţava prikaz korisnika u komponenti jList - void clearUserTFs() – briše unose iz komponenti jTextField - void enableUpdateButton() – omogućava/onemogućava dugme za aţuriranje korisnika - void enableInsertButton() - omogućava/onemogućava dugme za unos novog korisnika - void enableSetButton() – omogućava/onemogućava dugme za postavljanje novih kvota korisnicima - void updateUserExistsLabel() – prikazuje da li uneseni korisnik već postoji - void TFActions() – provjerava postojanje korisnika sa zadanim korisničkim imenom - void TFFindUser() – pretraţuje korisnike na osnovu unesenih parametara
51

Slika 4.12: Klasa MainGUI

4.3 GUI aplikacije Grafički izgled aplikacije je prilično jednostavan. Sastoji se od 4 dijela koja su lako dohvatljiva preko tabova. U principu SMTP i POP3 serveri su mogli funkcionirati i kao procesi pokrenuti u pozadini, meĎutim ovdje je dodan GUI prvenstveno radi administracije korisnika, a i da bi administrator mogao vidjeti status servera. Kada se pokrene, aplikacija izgleda kao na slici 4.13.

Slika 4.13: Početni izgled aplikacije Kao što se moţe vidjeti, inicijalno je odabran SMTP Server tab. Aplikacija prikazuje status servera (u ovom slučaju nije pokrenut), port na kojem se server vrti, i domenu. Port i domenu aplikacija čita iz settings.txt datoteke. Pored toga mogu se vidjeti dva dugmeta (button, engl.) kojima se pokreće i zaustavlja server (oba mogu biti omogućena ili onemogućena zavisno od statusa servera). Pritiskom na dugme START vrši se instantno pokretanje servera, dok se pritiskom na dugme STOP odbijaju sve daljnje konekcije na server, ali se dopušta već pokrenutim SMTP nitima da završe svoj posao. TakoĎer se moţe vidjeti Server log u kojem se prikazuje trenutna komunikacija servera i klijenta. Na slijedećoj je prikazan izgled SMTP servera kad je pokrenut.
52

Slika 4.14: SMTP server pokrenut Za POP3 server, koji se moţe pronaći na tabu POP3 Server, vrijedi potpuno isto što i za SMTP server.

Slika 4.15: Izgled taba POP3 Server

53

Slika 4.16: POP3 server pokrenut Na slijedećoj slici se moţe vidjeti administracija korisnika. U ovom tabu administrator ima slijedeće opcije:  Pretraga korisnika  Brisanje korisnika  Aţuriranje korisnika  Unos novog korisnika  Podešavanje kvote za sve korisnike U aplikaciji je napravljena logika da administrator ne moţe greškom unijeti jednog ili više korisnika sa istim korisničkim imenom (vrše se provjere kod unosa novog korisnika i kod aţuriranja). TakoĎer je stavljeno ograničenje da se ne moţe izbrisati korisnik sa korisničkim imenom postmaster, niti se moţe aţurirati njegovo korisničko ime, jer taj korisnik predstavlja administratora. Prilikom kreiranja novog korisnika predefinirana vrijednost za veličinu Mail Box-a je 100MB (izraţena u bajtima). Podešavanje kvote za sve korisnike se vrši unosom vrijednosti u polje Set MailBox size for all users i pritiskom na dugme SET (ovdje je moguće postaviti vrijednost u MB). Ako administrator ţeli unijeti novog korisnika, prvo treba označiti kvačicu New User i tek onda unositi vrijednosti u za to predviĎena polja. Administrator ne moţe unositi, niti mijenjati vrijednost trenutne zauzetosti korisničkog Mail Box-a, jer se ona automatski izračunava iz baze podataka. Slijedeća slika prikazuje izgled taba User administration.

54

Slika 4.17: Tab User Administration Ostao je još tab About. Na njemu su prikazane osnovne informacije o aplikaciji.

Slika 4.18: Tab About

55

4.4 Log datoteke Server kreira log datoteke u logs folderu koji se nalazi unutar instalacijskog foldera aplikacije. Log datoteke se kreiraju automatski svaki dan i to za svaki server odvojeno. U aplikaciju je dodana logika koja provjerava da li „današnja“ datoteka već postoji, i ako postoji server zapisuje podatke u nju, a ako ne, server kreira novu datoteku sa trenutnim datumom u obliku „VrstaServera—DD-MM-GGGG.txt“. Jedan log zapis predstavlja komunikaciju servera sa klijentom uz dodavanje vremena kada je ta komunikacija započeta, te domenu klijenta. Iz log zapisa je uklonjen payload mail poruke iz razloga privatnosti i iz razloga smanjivanja veličine log zapisa. Primjer log zapisa za SMTP server: Wed Feb 16 22:19:53 CET 2011 col0-omc1-s5.col0.hotmail.com S: 220 Terminator SMTP server at @adis.dyndns.info ready C: EHLO col0-omc1-s5.col0.hotmail.com S: 250 OK greets col0-omc1-s5.col0.hotmail.com C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK User recognized C: RCPT TO: S: 250 OK User recognized C: DATA S: 354 Start mail input; end wiht . S: 250 OK Data recieved(376879) C: QUIT S: 221 TFB.ba closing connection

4.5 Settings datoteka Datoteka za podešavanje parametara servera pod nazivom settings.txt se moţe pronaći u folderu settings unutar instalacionog foldera aplikacije. U toj datoteci se mogu podešavati portovi za oba servera te domena. Dodana je iz praktičnih razloga, da administrator servera u slučaju, na primjer, promjene domene, ne mora ponovo kompajlirati kod aplikacije, već je dovoljno da istu unese na predviĎeno mjesto u settings datoteci. Isto vaţi i za portove. Prilikom pokretanja aplikacije vrši se provjera zapisa u settings datoteci, te ako su oni ne valjani, ispisuje se greška i aplikacija se zatvara. Na taj način je spriječeno zauzimanje sistemskih resursa ako se oni ne mogu efektivno iskoristiti. Primjer postavki u settings datoteci: #Form of DataBase url is "jdbc:mysql://Database_ip:Database_port/Database_name db.url=jdbc:mysql://localhost:3306/diplomski db.user=root db.passwd=adis *numeric values must be between # and #, for example #25# smtpport = #25# pop3port = #110#
56

*domain name must include @ in front of domain name, and be between ' and ', for example '@domain.com' domain = '@adis.dyndns.info' 4.6 Primjer rada aplikacije Za testiranje aplikacije prvo je bilo potrebno registrirati domenu servera. To je učinjeno pomoću web servisa koji se moţe pronaći pod [www.dyndns.com], a omogućava besplatno kreiranje domene i dodjeljivanje iste dinamičkoj IP adresi. Kao klijent aplikacija korištena je Mozzila Thunderbird [link mozile], a moţe se koristiti bilo koja aplikacija namijenjena istoj svrsi (Outlook, Windows Live Mail, itd.). Cilj testiranja je bio provjeriti da li će biti uspješno poslan i primljen mail korisnika vanjskog mail servisa (Gmail) u Mail Box korisnika registriranog na našem serveru. Prvo je kreirana mail poruka pošiljaoca:

Slika 4.19: Testna mail poruka pošiljaoca Na slici se moţe vidjeti da je adresa pošiljaoca hodza.adis@gmail.com, adresa primaoca test1@adis.dyndns.info, da sadrţaj poruke sadrţi znakove iz bosanskog jezika, i da je u mail poruku dodan attachment pod imenom new.png. Nakon što je poruka uspješno isporučena na SMTP server, korisnik test1 je mogao pomoću POP3 servera dobiti obavijest da mu je stigla nova mail poruka. Korisnik test1 je uspješno otvorio i pročitao poruku i sa tim se smatra da je test uspješno završen.

57

Slika 4.20: Testna mail poruka uspješno primljena

4.7 Ograniĉenja Ograničenja aplikacije su uglavnom vezana za nedostatak financijskih sredstava potrebnih za implementaciju sigurnosnih mehanizama mail servera. Radi se o mehanizmima zaštite protiv SPAM poruka koja se mogu pročitati u odjeljku 3.1. Za uklanjanje ovih ograničenja potrebno je:  Zakupiti vlastitu domenu  Zakupiti stalnu IP adresu  Zakupiti autentifikaciju TSL certifikata  Zakupiti usluge koje pruţaju komercijalne blackliste (opcionalno) Razlozi ograničenja:  Blacklista – nepostojanje stalne IP adrese i domene  TSL – nepostojanje stalne IP adrese, domene i TSL certifikata  SPF – nepostojanje domene Zbog ovih ograničenja mail poruku sa našeg servera nije moguće poslati na servere koji koriste navedene sigurnosne mehanizme, meĎutim server moţe primati poruke sa svih ostalih mail servera na internetu. Treba napomenuti da implementacija mehanizama koji uklanjaju ova ograničenja nije propisana SMTP i POP3 standardom, meĎutim praksa u svijetu je da se oni ipak koriste.

58

5. ZAKLJUĈAK Najkraće rečeno, cilj ovog rada je bio uspješno obaviti inţinjerski projekt. Naučna istraţivanja obično rezultiraju kreiranjem skupa standarda i pravila, ali ne i konkretnim upotrebljivim proizvodom, za takvu svrhu su zaduţeni inţinjeri. Analogno tome, cilj ovog rada je bio da se na osnovu skupa standarda i pravila kreira jedan konkretan i upotrebljiv proizvod, što je, nadamo se, uspješno uraĎeno kreiranjem aplikacije „Mail server“. Iako navedena aplikacija ima nekih ograničenja, ona ipak predstavlja sasvim upotrebljivo rješenje spremno za korištenje praktički svugdje gdje je potreban jedan mail server. Naravno, aplikacija „Mail server“ se ne moţe mjeriti sa komercijalnim rješenjima slične vrste jer iz sebe nema programersku, tehničku i financijsku podršku kakvu imaju realizatori sličnih projekata, ali ova aplikacija moţe sluţiti kao izvrstan i jako širok temelj za daljnju nadogradnju i razvoj mail sistema neke ustanove. Iako je usluga elektronske pošte prisutna od samih prapočetaka interneta, nikako se ne moţe reći da se radi o zastarjeloj i nepotrebnoj usluzi. Impozantne brojke od gotovo 2 milijarde korisnika maila, što predstavlja više od četvrtine ukupnog stanovništva na zemlji) i nekoliko stotina milijardi poslanih poruka svaki dan , jasno govore o popularnosti ali i potrebi za mail porukama. Iako je dio tih poruka privatnog karaktera, neporeciva je činjenica da se mail koristi u svim granama ljudskog djelovanja, bilo da se radi o biznisu, školstvu, zdravstvu, ili nečem drugom, iz jednostavnog razloga jer se radi o brzom, lakom i jednostavnom komuniciranju. A još ako uzmemo u obzir trenutnu ekspanziju mobilnih mreţa, slobodno moţemo predvidjeti da će se broj korisnika, kao i broj razmijenjenih mail poruka, još više povećati. Budućnost maila je teška za predvidjeti. U dosadašnjem razvoju mail sistema vidljivo je da je uloţen značajan trud da bi se zadrţala kompatibilnost sa starijim mail sistemima, što je rezultiralo nešto sloţenijim standardima i protokolima, ali i globalnoj dostupnosti maila. Slobodno moţemo reći da se mail nije značajno mijenjao od osamdesetih godina, osim u pogledu brzine i dostupnosti (što je opet direktna zasluga ekspanzije interneta). Da li će budućnost maila donijeti neke promjene, ostaje nam samo da vidimo. Jedno je sigurno, mail će još dugo biti tu.

59

LITERATURA [1] [2] [3] [4] [5] [6] Panian, Ţ.: Bogatstvo interneta, Strijelac Zagreb, 2000. Panian Ţ.: Informatički enciklopedijski rječnik, Jutarnji List Zagreb, 2005. Kurose J., Ross K.: Computer Networking 4th Ed., Adison Wesley, 2007. Tanenbaum A.: Computer Networks 4th Ed., Prentice Hall, 2003. http://www.multicians.org/thvv/7094.html (Posjećeno 21.2.2011) http://www-03.ibm.com/ibm/history/exhibits/mainframe/images/2423PH7094.jpg (Posjećeno 22.2.2011) http://www.multicians.org/thvv/mail-history.html (Posjećeno 21.2.2011) http://www.radicati.com (Posjećeno 21.2.2011) http://wordnetweb.princeton.edu/perl/webwn?s=internet (Posjećeno 21.2.2011) http://en.wikipedia.org/wiki/Internet (Posjećeno 21.2.2011) http://www.rfc-editor.org/rfc/rfc1035.txt http://www.ietf.org (Posjećeno 22.2.2011) http://www.ietf.org/iesg/index.html (Posjećeno 22.2.2011) http://www.iab.org/ (Posjećeno 22.2.2011) http://www.ietf.org/rfc/rfc3935.txt (Posjećeno 22.2.2011) http://www.rfc-editor.org/rfc/rfc821.txt (Posjećeno 22.2.2011) http://www.rfc-editor.org/rfc/rfc5321.txt (Posjećeno 22.2.2011) http://www.rfc-editor.org/rfc/rfc918.txt (Posjećeno 22.2.2011) http://tools.ietf.org/rfc/rfc937.txt (Posjećeno 22.2.2011) http://www.rfc-editor.org/rfc/rfc1939.txt (Posjećeno 22.2.2011) http://tools.ietf.org/rfc/rfc1321.txt (Posjećeno 23.2.2011) http://www.rfc-editor.org/rfc/rfc3501.txt (posjećeno 25.2.2011) http://www.rfc-editor.org/rfc/rfc2045.txt (Posjećeno 23.2.2011) http://www.rfc-editor.org/rfc/rfc2046.txt (Posjećeno 23.2.2011)
60

[7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

[25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38]

http://www.rfc-editor.org/rfc/rfc2047.txt (Posjećeno 23.2.2011) http://www.rfc-editor.org/rfc/rfc2048.txt (Posjećeno 23.2.2011) http://www.rfc-editor.org/rfc/rfc2049.txt (Posjećeno 23.2.2011) http://tools.ietf.org/rfc/rfc4648.txt (Posjećeno 23.2.2011) http://mxtoolbox.com/blacklists.aspx (Posjećeno 23.2.2011) http://tools.ietf.org/rfc/rfc5246.txt (Posjećeno 23.2.2011) http://www.openspf.org/ (Posjećeno 23.2.2011) http://tools.ietf.org/rfc/rfc3851.txt (Posjećeno 23.2.2011) http://tools.ietf.org/html/rfc2315 (Posjećeno 23.2.2011) http://tools.ietf.org/rfc/rfc3174.txt (Posjećeno 23.2.2011) http://tools.ietf.org/rfc/rfc3156.txt (Posjećeno 23.2.2011) http://www.mysql.com/downloads/mysql/ (Posjećeno 23.2.2011) http://netbeans.org/ (Posjećeno 23.2.2011) http://www.oracle.com/technetwork/java/javase/downloads/index.html 23.2.2011) http://www.java.com/en/download/index.jsp (Posjećeno 23.2.2011) (Posjećeno

[39]

61