E-pošta po "jusu"
Prva elektronska pošta je bila poslana že davnega leta 1965. Vmes se ta, danes še vedno nadvse priljubljena in koristna storitev medmrežja ni prav dosti spreminjala in zato je tudi tehnologija, ki poganja ves ta poštni sistem, znana in naj bi jo znali pravilno "postaviti". Kljub temu se pri nastavljanju vseh sistemov, ki sodelujejo v sistemu elektronske pošte, še vedno dogajajo napake, ki uporabnost pošte postavljajo pod vprašaj.
Za dobro uporabniško izkušnjo elektronske pošte je potrebna pravilna nastavitev sistemov, ki omogočajo, da elektronska pošta iz enega strežnika sploh pride do naslovnika na drugem poštnem strežniku in da se za povrh ne ujame na sito nezaželene pošte. Poštni strežniki so načeloma ravno prav preprosti, da se njihovega postavljanja doma ali v podjetjih lotijo hišni informatiki s premalo izkušnjami. Pasti, kjer se lahko zapletemo v spiralo vzrokov in posledic, ki lahko na koncu pripeljejo do praktično neuporabne storitve, je kar nekaj - še posebej, če ne sledimo standardom (torej dokumentom RFC) ali priporočilom.
Že nekaj časa obstaja spletna stran www.postmasters.si, kjer je na voljo tudi nekaj orodij za preverjanje nastavitev strežnikov.
V različnih dokumentih RFC so bistre glave že pred več desetletji zapisale pravila in priporočila, ki se jih moramo držati pri komunikaciji v internetu.
Čarovnija DNS
Za začetek je treba pravilno urediti zapise DNS. Med pomembnejšimi parametri je pravilen PTR record, ki naj bo usklajen s pozdravnim sporočilom strežnika. Večinoma bo za to potreben klic do vašega ponudnika spletnih storitev, ki bo uredil, da se bo IP naslov poštnega strežnika pravilno pretvoril v ime strežnika. Torej gre za ravno nasprotno poizvedbo (reverse lookup) kot pri običajnem (forward pretvorba) poizvedovanju, ko iz imena strežnika dobimo IP.
Pri običajni poizvedbi:
ping mail.mladina.si
bomo dobili rezultat:
Pinging mail.mladina.si [85.10.32.195] with 32 bytes of data
Obratno poizvedbo bomo naredili takole:
ping -a 85.10.32.195
in spet dobili pravilno urejen odgovor
Pinging mail.mladina.si [85.10.32.195] with 32 bytes of data
Ali pa s tracert:
tracert 85.10.32.195
Tracing route to mail.mladina.si [85.10.32.195]
Pri nedefiniranem zapisu PTR pa bomo dobili približno tak rezultat:
Tracing route to 85-10-32-195.static.amis.net
Večina SPAM filtrov je danes zelo občutljivih na napačno nastavljen zapis PTR, še posebej pa jim gredo na živce "dynamic" (v zgornjem primeru sicer static), torej dinamični IP naslovi, s katerih prihaja večina nezaželene pošte, saj gre v takih primerih za okužene zombije. Ko bo naš SPAM filter preverjal, ali gre za legitimno pošto, bo preveril tudi pozdravni odziv našega strežnika in če ta ne bo enak tistemu pri obratni (reverse) poizvedbi, bo sporočilu pribil nekaj dodatnih točk, ki odločajo o tem, ali gre za zaželeno ali nezaželeno pošto.
Pozdravno sporočilo strežnika bomo preverili takole:
Telnet mail.mladina.si 25
Odgovor našega strežnika bo tak:
220 mail.mladina.si Microsoft ESMTP MAIL Service ready at Fri, 26 Feb 2010 00:01:01 +0100
Najpomembnejši del je za številko 220 in je v našem primeru mail.mladina.si in ta odgovarja zapisu PTR.
Če imate v zapisu DNS o domeni več zapisov MX, poskrbite, da bo proti nezaželeni pošti zaščiten tudi strežnik, ki ima nižjo prioriteto (torej večjo vrednost v zapisu MX), saj je znano, da onesnaževalci velikokrat sklepajo, da so poštni sistemi z nižjo prioriteto tudi slabše zaščiteni proti nezaželeni pošti. Če uporabljate poštni prehod (mail gateway), na primer Mailscanner, ali katero izmed drugih podobnih rešitev za čiščenje pošte, nastavite ciljni strežnik tako, da lahko sprejema pošto zgolj in samo od prehoda.
Ko gre za boj proti nezaželeni pošti, se izkaže, da bi lahko skorajda izkoreninili to nadlogo, če bi vse domene imele urejene zapise SFP. Najprej z orodjem nslookup preverite, ali vaša domena že ima tak zapis v txt polju cone DNS.
nslookup
>server ns.monitor.si
>set ty=txt
>monitor.si
in dobili bomo nekaj podobnega kot:
monitor.si text =
"v=spf1 a mx ptr a:mail.escape.si ~all"
monitor.si text =
"v=spf1 a mx ptr a:mail.mladina.si ~all"
Takle zapis smo dobili, kot smo v cono DNS za našo domeno zapisali tile vrstici:
@ IN TXT "v=spf1 a mx ptr a:mail.escape.si ~all"
@ IN TXT "v=spf1 a mx ptr a:mail.mladina.si ~all"
Tudi Google za obrambo pred nezaželeno pošto uporablja zapise SPF. Takole izgleda zapis za nekega uporabnika Google Apps.
Zapis SPF torej pove, kateri strežniki lahko za določeno domeno pošiljajo elektronsko pošto. Ko bo naš antispam filter preverjal posamezno poštno sporočilo, bo preveril, ali strežnik, s katerega sporočilo izvira, sploh lahko pošilja pošto za domeno, iz katere prihaja sporočilo. Če bi vam torej pošto poslal eden izmed Monitorjevih sodelavcev, bo vaš filter s poizvedbo DNS preveril, ali ima domena monitor.si zapis SPF. Ker ga ima, bo primerjal izvirni IP naslov sporočila z zapisom SPF in seveda ugotovil, da je poštno sporočilo legitimno, in vam ga dostavil v poštni predal. Sender Policy Framework (SPF) je podrobneje opisan v dokumentu RFC 4408.
Higiena poštnega strežnika in poštnih sporočil
Ena izmed hujših napak, ki jih lahko storimo pri nastavitvah poštnega strežnika, je ta, da dovolimo pošiljanje pošte komurkoli. Naredili smo si tako imenovani "open relay" in prej ali slej bomo postali odskočna deska za množično pošiljanje nezaželene elektronske pošte. Na strežniku SMTP je zato treba vklopiti avtentikacijo, ki omogoča pošiljanje pošte le tistim, ki jim to dovolimo. V spletu je na voljo kar nekaj testov, s katerimi lahko preverimo, ali nismo morda nevede ustvarili pohabljenega poštnega strežnika. Eden takih testov je prosto dosegljiv na naslovu
Priporočljivo je, da redno testirate stanje svojih poštnih strežnikov.
Da bo naš poštni sestav deloval po standardih RFC (konkretno RFC 2142), moramo imeti v poštnem sistemu delujoča naslova
in
Razume se, da je treba pošto, ki prihaja na ta dva naslova, tudi redno prebirati.
Še nedolgo tega so se virusi silno hitro širili s pomočjo priponk elektronski pošti (danes je tega že precej manj). Ko je protivirusni program na poštnem strežniku odkril, da je določeno sporočilo okuženo, je o tem obvestil pošiljatelja. Danes se tako početje šteje za odvečno in je povsem neučinkovito. Nezaželenih ali okuženih sporočil torej ne odbijajte (bounce), marveč jih sprejmite in nato zavrzite (če tako želite, seveda). Ker je večina nezaželene ali okužene pošte s ponarejenih e-poštnih naslovov, boste s takimi "obvestili" le prispevali k skupni količini nezaželene pošte v internetu.
Za konec: generični pripisi na vseh poštnih sporočilih, ki nas obveščajo, da je pošta namenjena samo naslovnikom in naj nemudoma pogledamo stran, če to nismo mi, ali pa da je bila pošta pregledana z enim izmed (ne)znanih protivirusnih programov, so povsem odveč in odvračajo pozornost od vsebine sporočila, nemalokrat pa zavzemajo nekajkrat več znakov kot stavek ali dva, ki smo ga morebiti želeli nekomu sporočiti.
Zgled pripisa na koncu vsakega sporočila, ki velikokrat para živce uporabnikom mobilnih telefonov, ki imajo majhne zaslone!
Dodatno branje
Dokumenti, ki se dotikajo tematike (in jih najlažje kar "poguglate"):
RFC 821 - Simple Mail Transfer Protocol
RFC 822 - Standard for the format of ARPA internet tex messages
RFC 2142 - Mailbox Names for Common Services, Roles and Functions
RFC 2045-2049 - Multipurpose Internet Mail Extensions (MIME)
