Izberite jezik

Kdo je pošiljatelj

Polja v glavi elektronske pošte
oz. kdo je resnični pošiljatelj nenaročene oglasne pošte

Članek opisuje, kako razbrati resničnega pošiljatelja elektronske pošte iz polj v njeni glavi. Dokument je primarno namenjen uporabnikom, ki prejemajo nenaročeno oglasno pošto (spam), a ne znajo razbrati resničnega pošiljatelja te pošte. Opisana so splošna navodila za odkrivanje pravega pošiljatelja elektronske pošte z opisom delovanje le te.

Vse pritožbe glede nenaročene oglasne pošte pri nas obravnava Tržni inšpektorat RS, več na to temo pa lahko preberete v sestavku o nenaročeni oglasni pošti.

V članku se nahaja kar nekaj izmišljenih domen in IP naslovov. V primeru, da bodo te domene in IP naslovi v prihodnosti obstajali, se ta članek ne nanaša na njihove bodoče uporabnike.

Kako deluje elektronska pošta

Odstavek opisuje življenjski cikel elektronskega pisma. Pomemben je za lažje razumevanje polj v glavi elektronske pošte.

Površno gledano se zdi, da elektronska pošta potuje direktno s pošiljateljevega na prejemnikov računalnik. V večini primerov ta trditev ne drži, saj mora elektronsko pismo prepotovati vsaj štiri računalnike.

Večina organizacij ima računalnik, ki mu pravimo poštni strežnik (mail server). V večini primerov to ni tisti računalnik, na katerem uporabniki berejo in pišejo elektronsko pošto. V primeru ponudnikov dostopa do interneta – npr. Arnes, je odjemalec tisti računalnik, ki se nahaja doma, ali npr. na šoli, strežnik pa se nahaja pri ponudniku storitev. Uporabnik elektronsko pismo napiše na svojem domačem računalniku, nato ga posreduje strežniku, ki se nahaja pri ponudniku storitev. Odjemalec za pošiljanje pošte je v tem primeru z delom zaključil, strežnik pa mora to pismo še dostaviti. To stori tako, da poišče prejemnikov strežnik, in mu ga dostavi. Pismo se nato dostavi naslovnikovemu strežniku, od koder ga naslovnik kasneje sprejme na svoj računalnik.

Primer:

Predstavljajmo si dva namišljena uporabnika Janeza in Lojza z elektronskima naslovoma in sicer:janez@fakulteta.si in lojze@ponudnik.dostopa.si.

Lojze se priključi na internet preko omrežje na klic ponudnika dostopa , za branje pošte pa uporablja program Loris Mail (ki je prav tako izmišljen); Janez je član fakultete in ima svoj računalnik povezan v fakultetno omrežje. Če želi Janez poslati pismo Lojzu, le tega napiše na svojem računalniku (njegov računalnik se recimo imenuje racunalnik17.fakulteta.si). Sporočilo se iz tega računalnika najprej posreduje na poštni strežnik mail.fakulteta.si. (V nadaljevanju Janez s tem sporočilom nima več kontaktov, saj se nadaljnje delo vrši na strežnikih.) Poštni strežnik ugotovi, da je pošta namenjena nekomu na naslovuponudnik.dostopa.si, zato “pokliče” poštni strežnik na tem naslovu (recimo mu npr.mail.ponudnik.dostopa.si) in mu dostavi pismo. Pismo bo sedaj čakalo na poštnem strežniku toliko časa, da Lojze pokliče s svojega domačega računalnika (imenujmo ga pentium.ponudnik.dostopa.si) in pregleda svojo pošto na strežniku. Pismo Janeza mu bo dostavljeno vključno z vso ostalo pošto, ki jo pričakuje.

Razlaga:

Med dostavo se bodo zapisi v glavo elektronske pošte dodali trikrat:

  1. Takrat, ko bo Janez pismo napisal in sicer s strani programa za pošiljanje pošte.
  2. Ko ta program pismo preda strežniku mail.fakulteta.si.
  3. Med prenosom pisma s Fakultete na Ponudnika dostopa. (Običajno vozlišče v omrežju na klic ne dodaja nobenih podatkov.)

Oglejmo si nastanek polj v glavi tega pisma.

    1. Pismo se generira v Janezovem programu za pošto in preda strežniku mail.fakulteta.si:

From: janez@fakulteta.si (Janez)
To: lojze@ponudnik.dostopa.si
Date: Tue, Mar 18 2003 14:36:14 PST
X-Mailer: Loris v2.32
Subject: Kosilo danes?

    1. Strežnik mail.fakulteta.si preda pismo poštnemu strežniku mail.ponudnik.dostopa.si:

Received: from racunalnik17.fakulteta.si (racunalnik17.fakulteta.si[124.211.3.11]) by mail.fakulteta.si (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: janez@fakulteta.si (Janez)
To: lojze@ponudnik.dostopa.si
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id: <janez031897143614-00000298@mail.fakulteta.si>
X-Mailer: Loris v2.32
Subject: Kosilo danes?

    1. Strežnik mail.ponudnik.dostopa.si zaključi z obdelavo pisma in ga shrani na disk, od koder ga bo Lojze lahko prevzel:

Received: from mail.fakulteta.si (mail.fakulteta.si [124.211.3.78]) bymail.ponudnik.dostopa.si (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 2003 14:39:24 -0800 (PST)
Received: from racunalnik17.fakulteta.si (racunalnik17.fakulteta.si[124.211.3.11]) by mail.fakulteta.si (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: janez@fakulteta.si (Janez)
To: lojze@ponudnik.dostopa.si
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id: <janez031897143614-00000298@mail.fakulteta.si>
X-Mailer: Loris v2.32
Subject: Kosilo danes?

Ob prejemu pisma, bo Lojze videl ravno to zadnjo glavo. Oglejmo si natančno analizo vseh polj v glavi tega elektronskega pisma.

Received: from mail.fakulteta.si

To pismo je bilo prejeto od strežnika, ki sebe imenuje mail.fakulteta.si

(mail.fakulteta.si [124.211.3.78])

… in mu je v resnici ime mail.fakulteta.si (se je pravilno predstavil – v nadaljevanju več o tem) in ima IP naslov 124.211.3.78.

by mail.ponudnik.dostopa.si (8.8.5/8.7.2)

Strežnik, ki je izvršil sprejem je mail.ponudnik.dostopa.si, uporablja program “sendmail” verzija 8.8.5/8.7.2 (ne skrbite, kaj te številke v resnici pomenijo…)

with ESMTP id LAA20869

Strežnik, ki je pismo prejel, je pismu dodelil številko LAA20869. (Ta podatek uporablja izključno strežnik – v primeru težav, lahko administrator potovanje dotičnega sporočila izsledi po datotekah z zgodovino – log files.)

for <lojze@ponudnik.dostopa.si>;

Pismo je bilo naslovljeno na lojze@ponudnik.dostopa.si. Upoštevajte, da ta del glave ni povezan s To:vrstico (več o tem v nadaljevanju).

Tue, 18 Mar 2003 14:39:24 -0800 (PST)

Predaja pisma se je zgodila v Torek (Tue.), 18. marca, 2003 ob 14:39:24 po pacifiškem času (ki je 8 ur za GMTjem (-0800).

Received: from racunalnik17.fakulteta.si (racunalnik17.fakulteta.si [124.211.3.11]) bymail.fakulteta.si (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)

To polje glave se je zapisalo ob predaji pisma Janezovega računalnika (racunalnik17.fakulteta.si) svojemu poštnemu strežniku (mail.fakulteta.si). Predaja se je zgodila ob 14:36:17 (po pacifiškem času). Računalnik, ki je pismo poslal strežniku se je predstavil kot racunalnik17.fakulteta.si in v resnici to tudi je, njegov IP naslov pa je 124.211.3.11. Fakultetni poštni strežnik uporablja program “sendmail” verzija 8.8.5, pismu pa je za interno rabo dodelil številko 004A21.

From: janez@fakulteta.si (Janez)

Pismo je poslal janez@fakulteta.si, ki se predstavlja z imenom Janez.

To: lojze@ponudnik.dostopa.si

Pismo je naslovljeno na lojze@ponudnik.dostopa.si.

Date: Tue, Mar 18 2003 14:36:14 PST

Pismo je bilo napisano ob 14:36:14 (Pacifiški čas) v torek, 18. marca, 2003.

Message-Id: <janez031897143614-00000298@mail.fakulteta.si>

To številko je pismu dodelil mail.fakulteta.si zaradi njegove identifikacije. Ta ID ni enak SMTP in ESMTP IDju v Received: polju, saj mu le ta ostane preko celotnega pošiljanja in sprejema – ostali IDji so lokalnega značaja in se nanašajo izključno na računalnike, ki so jih zapisali. Včasih (kot v tem primeru) je v Message-ID vključen tudi pošiljateljev elektronski naslov, ki pa nam pogosto ni berljiv.

Subject: Kosilo danes?

Zadeva pisma.

Protokoli za elektronsko pošto

Ta odstavek je bolj tehnične narave in se osredotoči na potovanje pisma od pošiljatelja do prejemnika. Celostno razumevanje tega odstavka vsekakor ni potrebno, vam bo pa vsaj okvirno poznavanje teme pripomoglo k razumevanju, kaj se dogaja s pošto v nenavadnih okoliščinah. Ker pošiljatelji nenaročenih oglasnih sporočil (neetični oglaševalci) namerno ustvarjajo takšne situacije (večinoma zato, da bi zmedli uporabnike), je razumevanje teh situacij zelo koristno.

Računalniki za pogovor preko mreže pogosto uporabljajo “vstopne točke” imenovane vrataVrata si lahko predstavljate kot kanal, skozi katerega računalnik posluša pogovore na mreži. Za poslušanje več pogovorov hkrati mora imeti računalnik odprtih več vrat. Za ločevanje so le ti oštevilčeni. Za sisteme, ki so priključeni na internet (oz. za vse sisteme, ki uporabljajo isti protokol za elektronsko pošto) so najpomembnejša vrata 25, ki se uporabljajo za sprejemanje in oddajo pošte.

Običajni scenarij

Oglejmo si še enkrat primer prejšnjega odstavka in se osredotočimo na komunikacijo med strežnikomamail.fakulteta.si in mail.ponudnik.dostopa.si. V resnici se tu zgodi slednje: mail.fakulteta.si odpre povezavo na vrata 25 z mail.ponudnik.dostopa.si in skozi to povezavo pošlje pismo skupaj z nekaj administrativnimi podatki. Ukazi in odgovori, ki se tu uporabljajo, so bolj ko ne berljivi. To so “ukazi v jeziku SMTP” (Simple Mail Transfer Protocol). Nekdo, ki bi prisluškoval pogovoru obeh strežnikov, bi “slišal” nekaj takega (ukazimail.fakulteta.si so napisani krepko):

220 mail.ponudnik.dostopa.si ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 2003 14:38:58 -0800 (PST)
HELO mail.fakulteta.si
250 mail.ponudnik.dostopa.si Hello mail.fakulteta.si [124.211.3.78], pleased to meet you
MAIL FROM: janez@fakulteta.si
250 janez@fakulteta.si… Sender ok
RCPT TO: lojze@ponudnik.dostopa.si
250 lojze@ponudnik.dostopa.si… Recipient ok
DATA
354 Enter mail, end with “.” on a line by itself
Received: from racunalnik17.fakulteta.si (racunalnik17.fakulteta.si [124.211.3.11]) bymail.fakulteta.si (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: janez@fakulteta.si (Janez)
To: lojze@ponudnik.dostopa.si
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id: <janez031897143614-00000298@mail.fakulteta.si>
X-Mailer: Loris v2.32
Subject: Kosilo danes?

Imaš danes čas za kosilo?

–Janez
.

250 LAA20869 Message accepted for delivery
QUIT
221 mail.ponudnik.dostopa.si closing connection

Celoten prenos sporočila temelji na petih ukazih, ki sestavljajo jedro SMTPja (obstaja še nekaj drugih, ki pa so večinoma samo pomožni procesi pri prenosu pošte z enega mesta na drugo):

  1. HELO
  2. MAIL FROM
  3. RCPT TO
  4. DATA
  5. QUIT.
  1. HELO identificira pošiljatelja; “HELO mail.fakulteta.si” lahko beremo kot “Pozdravljen, jaz semmail.fakulteta.si“. Pošiljatelj se lahko tudi laže, saj npr. fakulteti nič ne preprečuje, da se predstavi z “Pozdravljen, jaz sem blabla.xyzzyzx.si” (HELO blabla.xyzzyzx.si) ali celo “Pozdravljen, jaz sem narobe nastavljen računalnik” (HELO narobe nastavljen računalnik). Na srečo pa ima večina strežnikov orodja, s katerimi lahko odkrije prevaro in ugotovi pravo identiteto pošiljateljevega računalnika.
  2. MAIL FROM naznani obdelavo pisma. Pomeni pa “imam pošto od … in bi jo rad dostavil…”. Dani naslov se spremeni v pošiljatelja (From) na ovojnici (več o tem v nadaljevanju), ki pa sploh ni nujno enak pošiljateljevemu lastnemu naslovu! Ta očitna varnostna luknja je neizogibna (navsezadnje, računalnik, ki pisma sprejema ne more vedeti uporabniških imen na računalniku, ki pisma pošilja) in v določenih situacijah postane prav uporabna.
  3. RCPT TO je obraten MAIL FROM ukazu in definira načrtovanega prejemnika pisma. Eno sporočilo je lahko poslano več uporabnikom hkrati, tako da vključimo več RCPT TO ukazov (oglejte si razdelek s posredovanjem pošte, kjer piše, kako je ta možnost lahko zlorabljena na nezaščitenih računalnikih). Podani naslov se spremeni v “prejemnika na ovojnici” (več v nadaljevanju). S tem ukazom natančno definiramo, komu bo sporočilo poslano (ne glede na to, kaj piše v To: polju pisma).
  4. DATA prične z dejanskim pošiljanjem pisma. Vse, kar sledi ukazu DATA, se šteje kot del pisma, oblika le tega pa ni omejena. Vrstice na začetku sporočila (pred prvo prazno vrstico), ki se začnejo z eno samo besedo in dvopičjem, so del glave. Vrstica, ki vsebuje samo piko, pa zaključi pismo.
  5. QUIT prekine povezavo.

SMTP je popolnoma definiran v standardu RFC 821. Kopije posameznih RFCjev so na voljo na spletu. Slednji standard razjasni kompleksno obdelavo elektronske pošte. Celotna zbirka RFCjev je dostopna tudi na Arnesovem FTP strežniku.

Neobičajni scenarij

Zgornji scenarij je morda preveč poenostavljen. Naša predpostavka je, da imata strežnika omenjenih organizacij direktni dostop eden do drugega. Ob nastanku interneta je bilo to večinoma res (v redkih primerih to drži še danes). Ker pa nam varnost dandanes predstavlja vedno večjo skrb, večina elektronskih sporočil potuje tudi preko požarnega zidu ali preko več poštnih strežnikov v organizaciji.

Požarni zid

Večina organizacij priključuje svoje računalnike v internet z uporabo požarnega zidu. Požarni zid je računalnik, katerega glavna naloga je, da služi kot vratar med računalniki znotraj in zunaj organizacije (poizkuša preprečiti vdor v računalnike v organizaciji). S stališča strežnika, ki želi računalniku v organizaciji dostaviti pošto, to lahko pomeni, da se ne pogovarja direktno s tem računalnikom, temveč s požarnim zidom.

Za potovanje elektronskega pisma to predstavlja zgolj še en skok na poti do cilja. Požarni zid torej predstavlja le še en računalnik, ki je sodeloval pri dostavi pošte. Zgornji primer lahko priredimo za takšno situacijo:

Primer:

Takole bi izgledala glava pisma v primeru, da ima ponudnik.dostopa.si na svoji strani požarni zid. Pozorni bodite na prvo Recieved: vrstico (predpostavljamo, da se požarni zid imenuje firewall.ponudnik.dostopa.si. Poimenovanje požarnega zidu s “firewall” je načeloma neprimerno, saj s tem privabljamo vsakega mladostnika na svetu k poizkusu vdora v naš sistem).

Received: from firewall.ponudnik.dostopa.si (firewall.ponudnik.dostopa.si[121.214.13.129]) by mail.ponudnik.dostopa.si (8.8.5/8.7.2) with ESMTP id LAA20869 for <lojze@ponudnik.dostopa.si>; Tue, 18 Mar 2003 14:40:11 -0800 (PST)
Received: from mail.fakulteta.si (mail.fakulteta.si [124.211.3.78]) by firewall.ponudnik.dostopa.si (8.8.3/8.7.1) with ESMTP id LAA20869 for ; Tue, 18 Mar 2003 14:39:24 -0800 (PST)
Received: from racunalnik17.fakulteta.si (racunalnik17.fakulteta.si [124.211.3.11]) bymail.fakulteta.si (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: janez@fakulteta.si (Janez)
To: lojze@ponudnik.dostopa.si
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id: <janez031897143614-00000298@mail.fakulteta.si>
X-Mailer: Loris v2.32
Subject: Kosilo danes?

Če bi tudi pri fakulteti.si uporabljali požarni zid, bi pismo vsebovalo še eno Recieved: vrstico. Po istem principu bi lahko pri prenosu pisma sodelovalo tudi več računalnikov. Ni nujno, da so ti računalniki požarni zidovi – lahko so zgolj posredniki. Morda ima ponudnik.dostopa.si več poštnih strežnikov na različnih lokacijah in uporablja na primer en sam računalnik (npr. mailgate.ponudnik.dostopa.si) za določanje, na kateri poštni strežnik naj se pismo dostavi. Kljub temu, da je glava pisma v naslednjem primeru nenavadna, njen obstoj ni nemogoč.

Received: from mailgate.ponudnik.dostopa.si (mailgate.ponudnik.dostopa.si[121.214.11.102]) by mailhost3.ponudnik.dostopa.si (8.8.5/8.7.2) with ESMTP id LAA30141 for <lojze@ponudnik.dostopa.si>; Tue, 18 Mar 2003 14:41:08 -0800 (PST)
Received: from firewall.ponudnik.dostopa.si (firewall.ponudnik.dostopa.si[121.214.13.129]) by mailgate.ponudnik.dostopa.si (8.8.5/8.7.2) with ESMTP id LAA20869 for <lojze@ponudnik.dostopa.si>; Tue, 18 Mar 2003 14:40:11 -0800 (PST)
Received: from firewall.fakulteta.si (firewall.fakulteta.si [124.211.4.13]) by firewall.ponudnik.dostopa.si (8.8.3/8.7.1) with ESMTP id LAA28874 for <lojze@ponudnik.dostopa.si>; Tue, 18 Mar 2003 14:39:34 -0800 (PST)
Received: from mail.fakulteta.si (mail.fakulteta.si [124.211.3.78]) by firewall.fakulteta.si (8.8.5) with ESMTP id LAA61271; Tue, 18 Mar 2003 14:39:08 -0800 (PST)
Received: from racunalnik17.fakulteta.si (racunalnik17.fakulteta.si [124.211.3.11]) bymail.fakulteta.si (8.8.5) id 004A21; Tue, Mar 18 2003 14:36:17 -0800 (PST)
From: janez@fakulteta.si (Janez)
To: lojze@ponudnik.dostopa.si
Date: Tue, Mar 18 2003 14:36:14 PST
Message-Id: <janez031897143614-00000298@mail.fakulteta.si>
X-Mailer: Loris v2.32
Subject: Kosilo danes?

Potovanje pisma lahko restavriramo tako, da beremo Received: elemente od spodaj navzgor. Izracunalnik17.fakulteta.si -> mail.fakulteta.si -> firewall.fakulteta.si -> firewall.ponudnik.dostopa.si ->mailgate.ponudnik.dostopa.si -> mailhost3.ponudnik.dostopa.si, kjer je počakalo na Lojzev prevzem.

Posredovanje pošte (relaying)

Življenjski cikel pisma pa je lahko popolnoma drugačen od teh, ki smo si jih ogledali do sedaj, kar je lepo vidno v sledeči glavi pisma.

Received: from nakljucniposrednik.si (nakljucniposrednik.si [98.134.11.32]) bymail.fakulteta.si (8.8.5) id 004B32 for <janez@fakulteta.si>; Wed, Jul 30 2003 16:39:50 -0800 (PST)
Received: from vidim.si ([104.128.23.115]) by nakljucniposrednik.si (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 2003 19:36:28 -0500 (EST)
From: Anonimni oglaševalec <smeti@vidim.si>
To: (seznam prejemnikov izpuščen)
Message-Id: <w45qxz23-34ls5@nakljucniposrednik.si>
X-Mailer: Massive Annoyance
Subject: ŽELITE ZASLUŽITI VELIKO DENARJA???

Kljub temu, da veliko reči v tem pismu nakazuje, da gre za primer nenaročene oglasne pošte, se tu osredotočimo na Received: vrstice. Sporočilo izvira iz vidim.si, posredovano je bilo na strežniknakljucniposrednik.si in od tam k naslovniku na strežnik mail.fakulteta.si. Vse lepo in prav, vendar se vprašajmo, zakaj tu sodeluje strežnik nakljucniposrednik.si, saj nima čisto nič opraviti tako s pošiljateljem kot s prejemnikom?

Za lažje razumevanje moramo poznati nekaj osnov delovanja SMTPja. Vidim.si se je preprosto povezal na SMTP vrata na nakljucniposrednik.si in mu rekel “Pošlji to sporočilo na janez@fakulteta.si“. Ta je z ukazomRCPT TO: janez@fakulteta.si to tudi storil in na tej stopnji prevzel obdelavo pisma. Ker je bil naslovnik iz druge domene (fakulteta.si), je nakljucniposrednik.si poiskal poštni strežnik na tej domeni in mu pismo predal. Ta proces se imenuje posredovanje pošte (mail relaying).

Razlogi za posredovanje pošte izvirajo v osemdesetih letih prejšnjega stoletja, saj so takrat strežniki le redko pošiljali pošto z neposrednim pogovorom enega z drugim. Pogosteje so sestavili pot, po kateri bo pismo potovalo. To je bilo velikokrat težko izvedljivo, saj so morali pošiljatelji pot do prejemnika izdelati ročno. Če potegnemo analogijo s klasično pošto, je to tako kot pošiljanje pisma iz Pirana v Maribor. Na kuverto bi napisali:

Piran, Portorož, Izola, Koper, Postojna, Vrhnika, Ljubljana, Lukovica, Trojane, Celje, Maribor, Ulica Martina Krpana 6, Nadstropje 5, Janez Novak.

Popolnoma jasno je, zakaj je poštarju tak način naslavljanja prikladen. Če ste poštar v Piranu, je dovolj, če komunicirate samo s pošto v Portorožu (namesto da razmišljate, kako bi pismo poslali v Maribor ). Popolnoma jasno je tudi, da takšno naslavljanje ni prijazno do pošiljatelja in se zato praktično ne uporablja več.

Od tod torej izvira posredovanje elektronske pošte, ki je dovoljeno še danes. (Imam pošto zajanez@fakulteta.si, ki bi jo preko tebe poslal na vidim.si na repa.si na asdf.si na fakulteta.si – zato to imenujemo posredovanje pošte.

V današnjih časih posredovanje pošte običajno uporabljajo zgolj neetični oglaševalci, saj s tem poizkušajo prikriti pravi izvor pošte in preusmeriti pritožbe na tistega, ki je pošto posredoval. Prav tako posredovanje razbremeni strežnik oglaševalca, saj obdelavo naslovov in razpošiljanje pošte prevzame posrednik. Zdi se, da je izredno množično posredovanje celo kraja storitev (sredstev) posrednika. Bistveno je, da je bila vsebina pisma (iz uvodnega primera za posredovanje pošte) sestavljena pri vidim.si, posredniknakljucniposrednik.si pa je udeležen neprostovoljno. Nad pošiljateljem nima praktično nobenega nadzora (kot recimo pošta v Izoli nima nadzora nad nekom, ki piše pisma v Piranu). Vsak administrator pa lahko seveda izklopi možnost posredovanje pošte na svojem strežniku in se tako izogne zlorabi!

Pozorni bodimo še na eno podrobnost. Vrstico z Message-id: ni zapisal pošiljatelj (vidim.si), temveč posrednik (nakljucniposrednik.si). To je pogosta lastnost posredovanih sporočil, pove pa nam, da pošiljateljev računalnik ni v celoti izpolnil glave pisma.

Glava na ovojnici

V prejšnjih odstavkih smo lahko zaslutili, da glavi na pismu in na ovojnici tega pisma nista enaki. Zakaj je tako je opisano v tem odstavku.

Glavo na ovojnici običajno generira strežnik, ki je pošto sprejel. Received: polja se nanašajo na ovojnico, vendar pa se ta izraz običajno uporablja samo za “From” in “To” z ovojnice.

“From” z ovojnice se generira ob ukazu MAIL FROM. Če torej računalnik, ki želi poslati pošto reče: MAIL FROM: nekdo@vidim.si bo strežnik, ki je ta ukaz sprejel na ovojnico zapisal:

>From nekdo@vidim.si

Pozorni bodite na dvopičje, ki ga pri tem From ukazu običajno ni!

Prav tako pa se tudi “To” z ovojnice generira z RCPT TO ukazom. Če na primer računalnik, ki pošto pošilja sporoči: RCPT TO: lojze@ponudnik.dostopa.si, potem bo “To” na ovojnici lojze@ponudnik.dostopa.si. Pogosto je ta del glave izpuščen ali vključen v Received: polja.

Posledica obstoja naslovov z ovojnice je, da From: in To: s pisma lahko vsebujeta praktično katerokoli vrednost. Vsebino From: in To: na pismu torej izpolni pošiljatelj pisma, pismo pa se bo poslalo na naslov Toz ovojnice in ne na To: s pisma.

Primer SMTP prenosa:

HELO repa.si
250 mail.fakulteta.si Hello vidim.si [104.128.23.115], pleased to meet you
MAIL FROM:ponarejeni-naslov@repa.si
250 ponarejeni-naslov@repa.si… Sender ok
RCPT TO: lojze@ponudnik.dostopa.si
250 lojze@ponudnik.dostopa.si… Recipient OK
DATA
354 Enter mail, end with “.” on a line by itself
From:še-en-ponarejeni-naslov@poslovodja.si
To: (seznam prejemnikov izpuščen)
.
250 OAA08757 Message accepted for delivery

Izpiše sledečo glavo:

>From ponarejeni-naslov@repa.si
Received: from repa.si ([104.128.23.115]) by mail.fakulteta.si (8.8.5) for <lojze@ponudnik.dostopa.si>…
From: še-en-ponarejeni-naslov@poslovodja.si
To: (seznam prejemnikov izpuščen)

Pošiljatelj lahko definira tako From z ovojnice, kot tudi From: in To: s pisma, vsi ti podatki pa v tem primeru nimajo čisto nič skupnega z dejanskim pošiljateljem in prejemnikom. Zato nikoli ne zaupajmo FromFrom:in To: – še zlasti, če je pismo čudnega izvora, saj je te podatke zelo enostavno ponarediti.

Pomembnost Received: polj

Že v prejšnjih poglavjih smo lahko videli, da samo Received: polje hrani resnično zgodovino pisma in se lahko samo s pomočjo tega polja ugotovi, kdo je dejanski pošiljatelj (tudi, če je bilo pismo ponarejeno). V tem poglavju si bomo podrobneje ogledali, kako razbrati podatke iz tega polja v glavi pisma.

Edina zanesljiva zaščita pred ponarejanjem je Recieved: polje, ki ga je zapisal strežnik, takrat ko je pismo prejel od pošiljatelja. Ne pozabimo, da se lahko pošiljatelj še vedno lažno predstavi in vnese lažne podatke v HELO ukaz. Na srečo pa lahko sodobni programi za pošiljanje pošte to zaznajo in lažne podatke samodejno popravijo. Če bi na primer računalnik vidim.si z IP naslovom 104.128.23.115 poslal sporočilo na mail.fakulteta.si in ponaredil HELO repa.si, bi Received: vrstica izgledala takole:

Received: from repa.si ([104.128.23.115]) by mail.fakulteta.si (8.8.5)…

Čeprav fakulteta.si eksplicitno ne označi, da repa.si ni tisti računalnik, ki je sporočilo poslal, pa je IP naslov resničnega pošiljatelja shranjen. V primeru, da nekdo posumi, da repa.si ni pravi pošiljatelj sporočila, lahko v vsakem trenutku preveri IP naslov v pismu. Če torej sumimo, da pismo ni poslano z repa.si, (IP naslov 104.128.23.115), lahko to potrdimo s katerim od orodij za obratni dns (npr. z orodjem nslookup za UNIX, Windows…). Zabeležen IP naslov računalnika, ki je sporočilo poslal, zadostuje za potrditev suma ponarejanja – tako lahko z gotovostjo trdimo, da je bilo zgornje pismo poslano z vidim.si.

Nekateri sodobni programi za pošto ta proces že avtomatizirajo in ime resničnega pošiljatelja poiščejo sami. To iskanje imenujemo obratni DNS (reverse DNS), saj DNS iz imena poišče pripadajoči IP naslov. Če bi mail.fakulteta.si uporabljal takšno programsko opremo, bi Received: vrstica izgledala približno takole:

Received: from repa.si (vidim.si [104.128.23.115]) by mail.fakulteta.si

Iz zgornje vrstice je razvidno, da se je vidim.si z IP naslovom 104.128.23.115 predstavil kot repa.si. Verjetno ni potrebno poudariti, da je takšna informacija koristna za odkrivanje ponarejene pošte (Zato se neetični oglaševalci strežnikom, ki prikažejo ponaredbo, izogibajo). Obstajajo pa tudi strežniki, ki IP naslovov ne zabeležijo – k sreči takšnih strežnikov skorajda ni več.

Pogosto ponarejevalci elektronske pošte, preden pošto pošljejo, dodajo lažna Received: polja. To pomeni, da bi hipotetično Received: polja s pisma, poslanega s vidim.si lahko izgledale takole:

Received: from repa.si ([104.128.23.115]) by mail.fakulteta.si (8.8.5)…
Received: from nikjer by izmisljennaslov (8.8.3/8.7.2)…
Received: Tu ni nobenih informacij!

Povsem očitno je, da sta zadnji dve vrstici popolnoma nesmiselni in dodani s strani pošiljatelja pred dejanskim pošiljanjem pisma.

Ko pismo enkrat zapusti pošiljatelja, se Received: vrstice vedno dodajajo na vrh, zato se lahko ponarejene vrstice nahajajo samo na dnu glave. To pomeni, da lahko, če beremo glavo od zgoraj navzdol, sledimo potovanju pisma in zavržemo vse Received: vrstice, ki se nahajajo pod prvo ponarejeno.

Seveda pa lahko pošiljatelj, namesto očitnih smeti, vstavi tudi bolj avtentične Received: vrstice:

Received: from repa.si ([104.128.23.115]) by mail.fakulteta.si (8.8.5)…
Received: from poslovodja.si by repa.si (8.7.3/8.5.1)…
Received: from mraz.si by poslovodja.si (8.6.4)…

Ponarejanje je še vedno očitno, sej IP naslov ne pripada repa.si. Poneverbo bi še teže odkrili v primeru, če bi pošiljatelj navedel pravilna IP naslova za poslovodja.si in mraz.si. Kljub temu bi bilo ponarejanje še vedno vidno. Zapletena ponarejanja pisem k sreči niso pogosta.

Seznam pogostejših polj v glavi elektronske pošte

  • Apparently-To: Pošta z veliko naslovniki ima lahko v glavi dolg seznam vrstic (npr. Apparently-To: janez@fakulteta.si – po ena vrstica na prejemnika). Takšne vrstice nam povedo, da je bila pošta poslana preko poštnih seznamov, ki pa dandanes ne delujejo več na ta način.
  • Bcc: (Blind Carbon Copy) Če boste v glavi pisma slučajno videli tole vrstico, je zagotovo nekaj narobe. Uporablja se kot Cc: (v nadaljevanju), vendar se v glavi pisma ne izpiše. Tako lahko pošljete kopijo pisma tudi tistim, ki ne želijo, da se jim odgovarja ali pa ne želite razkriti njihovega naslova. To tehniko pogosto uporabljajo neetični oglaševalci, saj neizkušenega uporabnika z lahkoto zmedejo.
  • Comment: Ta vrstica ni standardna, dodajo pa jo nekateri programi za pošiljanje pošte (npr. Pegasus). Ker je vnos popolnoma prost, neetični oglaševalci to vrstico pogosto polnijo z zavajajočimi podatki.
  • Content-Transfer-Encoding: Nanaša se na MIME – standardiziran način za prilaganje vsebin elektronski pošti (vsebine, ki niso v tekstovni obliki). Na dostavo pošte to polje sicer ne vpliva, programu, ki to omogoča, pa pove, kako odpreti vsebino pisma.
  • Content-Type: Še eno MIME polje, ki programu pove, kako odpreti priloženo vsebino.
  • Date: To polje običajno vsebuje datum, ko je bilo pismo poslano. Če uporabnikov program za pošiljanje pošte tega polja ni dodal sam od sebe, ga lahko doda katerikoli strežnik na poti. Podatek ni vedno realen, saj ima veliko število računalnikov napačno nastavljen čas.
  • Errors-To: Poda naslov, na katerega naj se javijo napake, povezane s pošiljanjem pošte. (npr. ni uporabnika, …) Pojavi se zelo redko, saj pošiljatelj ponavadi želi obvestilo o napaki prejeti izključno na naslov, s katerega je pošto poslal (privzeto delovanje poštnih strežnikov).
  • From (brez dvopičja) Predstavlja From z ovojnice.
  • From: (z dvopičjem) Predstavlja From: na pismu.
  • Message-ID: (tudi Message-id:) Polje se običajno doda takrat, ko sporočilo prvič pride na poštni strežnik. Je tipa blabla@fakulteta.si, kjer lahko za del blabla vnesemo katerokoli vrednost, drugi del pa predstavlja ime strežnika, ki je ta ID pismu dodelil. Včasih je v delu blabla tudi uporabniško ime pošiljatelja sporočila. Če pismo vsebuje ID brez znaka @ ali če v njem ni vpisanega pravega porekla pisma, gre verjetno za ponarejanje.
  • In-Reply-To: Polje je povezano z Usenet skupinami. Pojavlja se v tistih pismih, ki so bila direktni odgovor na neko Usenet temo. To polje je pogosto zlorabljeno, saj z njim poizkuša zmesti programe za avtomatsko sortiranje pošte.
  • Mime-Version: (tudi MIME-Version:) Še eno MIME polje, ki poda verzijo MIME protokola, ki ga je uporabil pošiljatelj. Kot ostala MIME polja, se lahko tudi tega ignorira.
  • Newsgroups: Pojavlja se samo v pošti, ki je povezana z Usenet skupinami. Vsebuje lahko imena Usenet skupin, na katere je bilo pismo poslano ali vsebuje skupine, na katere se je odposlal odgovor.
  • Organization: Polje je popolnoma prosto. Običajno vsebuje ime organizacije, preko katere je pošiljatelj priključen v splet. Uporabnik lahko tu vpiše, kar želi.
  • Priority: Načeloma prosto polje, ki pismu dodeljuje pomembnost. Programi za elektronsko pošto ga večinoma ignorirajo, ga pa velikokrat uporabijo neetični oglaševalci (običajno Priority: Urgent).
  • Received: Opisano v prejšnjem delu dokumenta.
  • References: Uporablja se samo v kopijah prispevkov Usenet skupin. Pomaga nam pri identifikaciji prispevkov, na katere pismo odgovarja. Če se pojavi v pismu, je običajno samo kopija kakšnega polja v glavi Usenet prispevka, lahko pa tudi identifikacijska številka tistega prispevka, na katerega odgovarjamo.
  • Reply-To: Poda naslov, na katerega bodo prispeli odgovori. Uporablja se takrat, ko odgovore na pošto ne želimo prejeti na tisti naslov, s katerega smo jih poslali. Neetični oglaševalci v to polje običajno vstavijo neveljavne naslove, kamor potem prihajajo pritožbe.
  • Sender: Pojavlja se le redko (običajno se uporablja X-Sender:) in še to samo v Usenet skupinah. Identificira pošiljatelja (Sender: polje je pri Usenet skupinah bolj zanesljiv identifikator pošiljatelja kot From:).
  • Subject: Popolnoma prosto polje, ki ga določi pošiljatelj, opisuje pa zadevo pisma, oziroma pove, na kaj se pismo nanaša.
  • To: Enakovredno message To: polju. To polje ni nujno zasedeno.
  • X-headers: Je splošni izraz za polja, ki se začnejo z velikim X in nadaljujejo s pomišljajem. Ta polja so nestandardna in služijo zgolj v informativne namene. Konvencija se pogosto krši.
  • X-Confrim-Reading-To: Polje zahteva pošiljanje avtomatske potrditve avtorju, ko je bilo pismo prebrano. Večina programov za pošto to polje ignorira.
  • X-Distribution: Polje je dodal avtor programa Pegasus. Če je neko pismo s programom Pegasusposlano na veliko naslovov hkrati, se v polje doda vrednost “bulk“. Mišljeno je predvsem za sortiranje pošte.
  • X-Errors-To: Enakovredno polju Errors-To:. Podaja naslov, na katerega se bodo poslale napake, ki nastanejo pri pošiljanju pošte.
  • X-Mailer: (tudi X-mailer:) Prosto polje, v katerega se podpiše program, s katerim je bila pošta poslana. Ker večina neetičnih oglaševalcev za razpošiljanje uporablja svoje programe, lahko to polje uporabimo za sortiranje.
  • X-PMFLAGS: Polje doda program Pegasus. Ne pove pa nič takega, kar ni že vpisano v X-Mailerpolju.
  • X-Priority: Še eno polje za označevanje pomembnosti, uporablja pa ga program Eudora.
  • X-Sender: Enakovredno polju Sender.
  • X-UIDL: Polje se doda med prenosom pošte s sprejemnikovega strežnika na lokalni računalnik preko POP protokola. Če pošta s takšnim poljem prispe že na strežnik, gre po vsej verjetnosti za nenaročeno oglasno pošto.

 


Avtor prispevka je Nathan Tenny,
Copyright 1997-2004 by Ken Lucke – all rights reserved.

Prevod in priredba: ARNES, januar 2004

Dodaj odgovor