Elektronska pošta
Sprememba naslova za elektronsko pošto (in naslova osebne strani (URL))
Vsebina
Nastavitve bralnikov
Windows 10: Izberemo aplikacijo Pošta. Izberemo Dodaj račun. Poiščemo možnost Napredne nastavitve. Nato izberemo možnost Internetna e-pošta (Računi POP ali IMAP, ki omogočajo, da e-pošto ogledujete v spletnem brskalniku). Ime računa je ime, ki se vam bo pokazalo v aplikaciji na levi strani. Izpolnimo vrstico Vaše ime. Pri vrstici Strežnik za dohodno e-pošto vpišite: mailbox.ijs.si. Pri Vrsta računa izberemo IMAP4. Uporabniško ime je vaš e-mail naslov. Strežnik za odhodno e-pošto (SMTP) nastavimo mailbox.ijs.si. Na koncu pustimo obkljukane vse 4 vrstice (Strežnik za odhodno e-pošto zahteva preverjanej pristnosti; Za pošiljanje e-pošte uporabi isto uporabniško ime in geslo; Zahtevaj SSL za dohodno pošto, Zahtevaj SSL za odhodno pošto).
MacOS X: Če uporabljamo aplikacijo Mail. Izberemo Dodaj drug račun. Vnesemo e-mail naslov ter geslo. Pri okencu z nastavitvami, vnesemo uporabniško ime. Za Tip računa izberemo IMAP. Za Odhodno e-pošto napišemo mailbox.ijs.si. Za Dohodno e-pošto napišemo mailbox.ijs.si. Če imamo inštaliran Microsoft Office, izberemo aplikacijo Microsoft Outlook. Vnesemo naš poštni naslov. Če nam ne ponudi nastavitev izberemo IMAP/POP. Ko nam ponudi nastavitve, pri vrstici Tip izberemo IMAP. Pri vrstici naslov Naslov elektronske pošte vnesemo email naslov. Pri vrstici Uporabniško ime vnesemo poljubno uporabniško ime. Za Dohodno e-pošto napišemo mailbox.ijs.si, port 993. Pustimo obkljukano Uporabi SSL za povezavo. Za Odhodno e-pošto napišemo mailbox.ijs.is, port 587. Pustimo obkljukano Uporabi SLL za povezavo.
Pri bralnikih pošte MS Outlook in Outlook Express izberemo avtentikacijo in šifriranje na podoben način, obe lastnosti sta vezani na uporabniški račun (account). Varno avtentikacijo za prejemanje pošte lahko vklopimo z opcijo Log on using secure password authentication pri nastavitvah strežnika za dohodno pošto (Incoming server (IMAP: mailbox.ijs.si, šifrirano preko SSL, port 993. Če šifriramo preko TLS ali ne šifriramo, potem uporabimo port 143). Za avtentikacijo pri oddajanju pošte izberemo My outgoing server requires authentication pri nastavitvah odhodnega strežnika ( Outgoing server (SMTP: mailbox.ijs.si, port 587. Če uporabimo SSL poterm je port 465 (priporočljivo za uporabo na zunanjih računalnikih)). Izberemo tudi Use same settings as my incoming mail server.
Šifriranje (TLS oz. SSL) lahko izberemo neodvisno za dohodni in za odhodni strežnik: This server requires encrypted connection. Če je zveza šifrirana, ni nujno, da je vklopljen tudi Log on using secure password authentication pri IMAP, škodi pa ne.
Pri bralniku Thunderbird: Edit -> Account settings -> Server settings izberemo: Use secure connection -> TLS, if available in Use secure authentication. Pod Outgoing server (SMTP) pa: TLS, if available in port 587.
Pri bralniku KMail v KDE okolju velja podobno. Pri nastavitvah računa izberemo Receiving -> Security -> Use TLS for secure mail download, za Authentication Method pa DIGEST-MD5. Za odhodno pošto pa: Sending -> Security: TLS, in Authentication Method: DIGEST-MD5. Številko vrat nastavimo pod Receiving -> General > port 993 in za pošiljanje pod Sending -> General > port 587.
Bralnik Opera ima nastavitve pod Tools -> Mail and chat accounts. Tudi tu velja IMAP prek TLS na vratih 993 in SMTP prek TLS na vratih 587. Avtentikacijo lahko pustimo nastavljeno na avtomatsko.
Pošiljanje pošte (SMTP)
SMTP-strežnik za oddajo pošte je mailbox.ijs.si, tcp port 587 (priporočljivo, ker je namenjen prav temu) ali tcp port 25 (splošni poštni servis). Pri oddaji sporočil z institutskih računalnikov avtentikacija (SASL) ni obvezna, je pa dovoljena. Pri oddajanju sporočil z zunanjih računalnikov je avtentikacija uporabnika obvezna. Uporabniško ime in geslo sta enaka kot za dostop do poštnih predalov (branje pošte). SMTP-strežnik podpira tudi šifriranje prometa prek TLS (port 587) ali prek starejšega mehanizma SSL (port 465), ni pa uporaba šifriranja obvezna. Vklop šifriranja prometa je priporočljiv zlasti pri oddaji pošte z zunanjih računalnikov.
SMTP-strežnik podpira naslednje avtentikacijske mehanizme: DIGEST-MD5 (priporočljivo), manj primerno: CRAM-MD5 ali NTLM in nezaščiteno: PLAIN. Uporaba nezaščitenega gesla je primerna le, če je vklopljeno šifriranje prometa (TLS ali SSL).
Sprejemanje pošte (IMAP in POP3)
Strežnik mailbox.ijs.si podpira oba protokola za dostop do poštnih predalov, preprostejši POP3 (tcp port 110 ali šifrirano s SSL prek 995) in zmogljivejši IMAP (tcp port 143 (šifrirano/TLS ali nešifrirano) ali šifrirano s SSL prek 993). Priporočamo le uporabo protokola IMAP. Protokol POP3 se lahko uporablja le v primeru, da se do poštnega predala dostopa samo z enega (vedno istega) računalnika znotraj IJS. Dostop od zunaj (npr. od doma) je smiselen le prek protokola IMAP.
Avtentikacija uporabnika prek IMAP je možna prek naslednjih mehanizmov: DIGEST-MD5 (priporočljivo), manj primerno: CRAM-MD5 ali NTLM in nezaščiteno: clear text. Uporaba nezaščitenega gesla je dovoljena le, če je vklopljeno šifriranje prometa (TLS ali SSL).
Spletni bralnik
Eden od možnih bralnikov pošte je tudi IMAP-klient, ki teče na institutskem računalniku (nasprotno od drugih, ki tečejo neposredno na uporabnikovem računalniku) in je prek protokola HTTPS dostopen na naslovu https://nabiralnik.ijs.si/ ali https://webmail.ijs.si/. Ta bralnik pošte ima nastavitve za branje in pošiljanje (ime strežnika, protokol, avtentikacijske opcije) že vgrajene in jih ni mogoče spreminjati, vedno se poveže na strežnik poštnih predalov mailbox.ijs.si prek protokolov IMAP in SMTP. Uporaben je v primerih, da na nekem tujem računalniku le gostujemo in ne moremo (ali ne želimo) namestiti ali spremeniti nastavitev bralnika pošte na tistem računalniku, imamo pa na voljo spletni dostop, na primer v kiber-kavarnah ali kot udeleženci konferenc po svetu.
Ta bralnik je po načinu dostopa do poštnega predala enakovreden drugim IMAP-bralnikom, ima pa nekatere omejitve in ni posebno primeren za branje in pošiljanje velikih sporočil ali za pregled velikega števila sporočil. Uporabljajte ga predvsem takrat, ko ni možno uporabiti bralnika pošte neposredno na osebnem računalniku.
Nabor znakov in slovenščina, izbira kodiranja
Pri programu Microsoft Outlook Express je treba biti pozoren, da je izbrani format kodiranja MIME, in da 8-bitni znaki v glavi sporočila niso dovoljeni.
Na kratko za Outlook Express:
Tools -> Options -> Send -> Mail Sending Format -> Plain & HTML Settings:
(da) MIME format Encode text using: Quoted Printable (lahko tudi none) (ne!) Allow 8-bit characters in headers
Tools -> Options -> Send -> International Settings:
Default encoding: Central European (ISO) ali Unicode (UTF-8)
(da) When replying to messages always use English headers
V programu Microsoft Office Outlook velja podobno, nastavitve so pod:
Tools -> Options -> Mail Format -> Internet format:
- plain text options:
(ne!) Encode attachments in UUENCODE format when sending a plain text message
Compose/Send in this message format: Plain Text ali HTML (ne: Rich Text Format)
Tools -> Options -> Mail Format -> International Options:
- (da) Use English for message flags (da) Use English for message headers on replies and forwards (da) Auto select encoding for outgoing messages Preferred encoding for outgoing messages: Central European (ISO) ali Unicode (UTF-8)
Glej tudi: https://support.microsoft.com/kb/290809
Če imamo starejšo programsko opremo, ki se ne znajde najbolje v sodobnem večjezičnem svetu, predlagamo njeno posodobitev ali namestitev odprtokodnega programa Mozilla Thunderbird (in njegovega tovariša za branje spletnih strani Mozilla Firefox). Oba tečeta pod MS Windows in pod Unix/Linux operacijskimi sistemi:
https://www.mozilla.org/projects/thunderbird/ https://www.mozilla.org/en-US/firefox/ https://www.mozilla.org/projects/seamonkey/
Za sisteme Unix ali Linux je dobra rešitev tudi poštni bralnik KMail za okolje KDE.
Pošiljateljev naslov in pripadajoči strežnik
Pri oddaji e-poštnega sporočila postaja vse pomembneje, da se domena v poštnem naslovu pošiljatelja (naslov From:) ujema z domeno SMTP-strežnika, kateremu oddamo svoje sporočilo, ne glede na to, kako smo trenutno priključeni v omrežje.
Če je naš naslov (pošiljateljev naslov) oblike uporabnik@ijs.si, je koristno vedno oddajati sporočila institutskemu strežniku mailbox.ijs.si, tudi če smo v tujem omrežju (npr. iz domačega računalnika v omrežjih Siol, Amis, Telemach, Arnes ali iz tujine).
Kadar uporabimo neinstitutski pošiljateljev naslov (npr. gmail.com, yahoo.com, guest.arnes.si, siol.net, ...) velja isto načelo, kar pomeni, da je pametno oddajati taka sporočila neposredno strežniku tiste domene, če je le mogoče, npr. na mail.arnes.si, smtp.amis.net, smtp.siol.net, smtp.planet.si, smtp.gmail.com, oziroma prek spletnega strežnika tistih domen, ki ne podpirajo oddaje sporočil prek protokola SMTP (yahoo.com, ...).
Razlog za tak nasvet je vedno bolj uporabljano preverjanje pristnosti sporočil, ki jih opravljajo prejemnikovi poštni strežniki ali bralniki pošte. Mehanizmov za tako preverjanje je več, vendar je skoraj vsem skupno to, da ugotavljajajo, ali je sporočilo prispelo s tiste domene, ki jo je uporabil pošiljatelj v svojem naslovu. Kadar se pošiljateljev naslov ne ujema z izvorom sporočila, lahko prejemnik tako sporočilo obravnava kot drugorazredno sporočilo, pri katerem je verjetnost, da gre za ponaredek ali za spam povečana, tako je tudi verjetnost zavrnitve večja.
Ta nasvet je v nasprotju z nasvetom izpred let, ko je bilo priporočeno, da poštna sporočila oddajamo strežniku v tistem omrežju, v katerem se trenutno nahajamo. Danes to ni več priporočljiva praksa, današnja praksa je opisana v RFC 5068. Hkrati je tudi razvoj avtentikacijskih in varnostnih mehanizmov močno olajšal oddajo sporočil domačemu strežniku tudi potujočim ali domačim uporabnikom (RFC 2554, RFC 4422).
Oddajanje sporočil institutskemu strežniku je še vedno dovoljeno tudi z navedbo tuje domene pošiljatelja, tako npr. z IJS lahko oddamo sporočilo in navedemo svoj gmail.com-naslov, če ga imamo. A pri tem sporočila ne bo podpisal Gmail strežnik, in prejemnikom se zato lahko zdi sumljivo.
In nasprotno: strežniku mail.arnes.si ali smtp.amis.net lahko oddamo svoje sporočilo in v njem uporabimo svoj institutski naslov oblike uporabnik@ijs.si, a takega sporočila poštni strežnik na IJS ne bo mogel podpisati (ker sporočilo ne potuje skozenj), strežnik na arnes.si oz. amis.net pa ga ne bo niti mogel niti hotel podpisati z IJS-podpisom - zato je lahko prejemniku sumljivo.
Za zagotavljanje pristnosti sporočil, odposlanih s strežnika na IJS od avgusta 2006 podpisujemo sporočila z digitalnim podpisom po določilih DomainKeys Identified Mail (DKIM) (RFC 6376), tako kot to počneta na primer Gmail in Yahoo! .
Še nasvet glede oddajanja sporočil prek protokola SMTP, ki smo ga že navedli v prvi točki tega dokumenta (Pošiljanje pošte): kadar je le mogoče, oddajamo pošto na tcp vrata 587, ki so temu namenjena (RFC 4409), in ne na tcp vrata 25. Pogosto namreč požarni zid omrežja, v katerem se nahajamo, ne dovoljuje odhodnih povezav na tcp vrata 25 - glavni razlog je preprečitev širjenja okužbe ali razširjanja spama, kadar se zgodi, da se kak notranji (ali domači) računalnik okuži. Žal vsi ponudniki storitev še ne podpirajo predaje pošte lastnim uporabnikom prek vrat tcp 587, a stanje se izboljšuje. Kadar oddaja na vrata tcp 587 ni možna, hkrati pa so zveze na tcp vrata 25 blokirane, je včasih možna oddaja sporočil prek tcp vrat 465 (SSL) ali prek spletnega strežnika domene -- lahko pa oddamo sporočilo strežniku omrežja, v katerem se nahajamo, in se sprijaznimo z morebitno drugorazredostjo takega sporočila.
Pogosta vprašanja z odgovori
Kako lahko zaide k meni pošta, čeprav je naslovljena na nekoga drugega?
Ne more. Vir zmote je nepravilno tolmačenje To: in Cc: polj v glavi sporočila (RFC 5322), ki so le informativnega značaja in ne vplivajo na dostavo pošte. Naslovi prejemnikov se posredujejo prek protokola SMTP (RFC 5321) neodvisno od glave in vsebine sporočila, tem naslovom pravimo ovojnica sporočila. Naslovi iz ovojnice sporočila niso nujno enaki tistim v glavi sporočila. Včasih je neujemanje očitno in ni zavajajoče, včasih pa je na prvi pogled sumljivo, vendar ni napačno.
Primer neujemanja pri navedbi skritih (Bcc) naslovov prejemnikov:
Pošiljatelj navede naslednje prejemnike:
To: glavni@example.com Bcc: drugi@example.com, tretji@example.com
Seznam prejemnikov v ovojnici je: glavni@example.com, drugi@example.com, tretji@example.com, vsi so med seboj enakovredni. Polje glave Bcc: (blind-carbon-copy) se pri pošiljanju izbriše iz glave, tako da vsi trije prejemniki vidijo v glavi sporočila le To: glavni@example.com. Prejemnika drugi@example.com in tretji@example.com se morda čudita, kako je prišlo sporočilo do njiju, a začudenje je odveč, tu ni nobene nepravilnosti.
Primer neujemanja pri pošiljanju prek poštnih seznamov:
Pošiljatelj navede prejemnika:
To: seznam@example.com
V ovojnici sporočila, ki prispe do strežnika poštnih seznamov, je le en naslov seznam@example.com, ki pa ga ta strežnik zamenja s celotnim seznamom članov poštnega seznama, ne da bi pri tem tudi zamenjal polje To: v glavi. Vsi člani poštnega seznama vidijo v glavi sporočila To: seznam@example.com in se običajno ne čudijo, kako je sporočilo lahko prišlo do njih. V prvem in drugem primeru je mehanizem enak, razlika v tolmačenju je le morda v pričakovanjih prejemnika.
Primer neujemanja pri preusmeritvi:
Preusmeritev pomeni, da sporočilo, ki prispe na neki naslov, pošni strežnik samodejno preusmeri na neki drug naslov, ki je lahko ali pa tudi ne v isti domeni. Tako so na primer včasih preusmerjeni psevdonimi ali dekliški naslov na uradni naslov (ivan@example.com -> janez@example.com), ali pa je nastavljena preusmeritev pri selitvi uporabnika (ivan@example.com -> i324@gmail.com). Pošiljatelj navede v glavi sporočila:
To: ivan@example.com
in sporočilo pristane v poštnem predalu janez@example.com oziroma v i324@gmail.com, v glavi sporočila pa še vedno stoji To: ivan@example.com. Podobno velja pri ročni preusmeritvi (resend).
Primer neujemanja pri nezaželeni komercialni pošti (spam):
Tu je neujemanje pogosto najbolj očitno, v glavi sporočila je na primer naveden en naslov:
To: xxx@example.com
morda se sporočilo celo začenja z Dragi xxx, hkrati pa je program za razpošiljanje spam sporočila v ovojnici navedel drug naslov, ali pa celo vrsto naslovov prejemnikov. Tudi tu ni nobene nepravilnosti, le prejemnik ne sme poljema glave To: in Cc: pripisovati pomena, ki ju nimata.
Dobil sem sumljivo sporočilo od znanega pošiljatelja, ki pa ga on (najbrž) ni poslal
Naslov pošiljatelja je podatek, ki ga je zelo lahko ponarediti, hkrati pa istovetnost tega naslova nima posebnega vpliva na dostavo pošte. 'Izposoja' tujega poštnega naslova je prijem, ki se ga poslužuje večina zlonamerne in oglasne pošte, pa tudi večina poskusov 'socialnega inženirstva' in drugih goljufij, kjer poskuša pošiljatelj pretentati nepozornega ali lahkovernega prejemnika in mu izmamiti kakšne podatke z namenom kraje identitete ali dostopa do osebnih podatkov -- tako imenovan 'phishing'.
Večino tovrstnih sporočil se da prepoznati že iz vsebine brez posebnega truda: uporaba tujega jezika v sporočilu od slovenskega pošiljatelja, latovščina v prevodu izvirajoča iz avtomatskega prevajanja, nenavadne ali sumljive zahteve po podatkih od nekoga, ki bi jih moral že poznati ali ki nima pravice oziroma potrebe po njih, potreba po nujnem in takojšnjem ukrepanju, navedba spletnih povezav do strežnikov v tujini kamor je treba nekaj javiti, zahteva da se pošlje odgovor na nek nenavaden naslov, ipd.
Z malo več truda lahko pogledamo v glavo sporočila, kjer se iz Received: vrstic zanesljivo vidi, s katerega poštnega strežnika je sporočilo zares prišlo. Če je prispelo iz tujine, hkrati pa navaja kot pošiljatelja slovenski poštni naslov, je to dober razlog, da s takim sporočilom ravnamo zelo previdno in z veliko mero dvoma o avtentičnosti. Če ste v dvomu, raje vprašajte navedenega pošiljatelja, če ga poznate, ali pa se obrnite po pomoč k sodelavcu ali administratorju e-pošte.
Če le obstaja kanček dvoma o pristnosti sporočila, nanj ne odgovarjajte, predvsem pa ne pošiljajte svojih osebnih podatkov, gesel, številk bančnih in drugih kartic ali računov, ne da bi se pred tem temeljito prepričali o tem, komu in zakaj jih pošiljate. Tudi ne dostopajte nepremišljeno do spletnih povezav navedenih v sumljivih sporočilih - tu preži več pasti, denimo URL povezava, ki zgleda kot prava, a se od prave razlikuje le v kakšni črki ali številki, npr amaz0n.com namesto amazon.com. Pa tudi ne nalagajte in ne poganjajte programov, ki bi bili pripeti sporočilu ali priporočeni s povezavo v sumljivem besedilu.
Več o tem: https://www.cert.si/ , https://en.wikipedia.org/wiki/Phishing
Prepričljivejše oziroma manj prozorne poskuse goljufij, ki bi jim lahko kdo nasedel, je primerno javiti na SI-CERT pri Arnes, še zlasti če se ob analizi glave sporočila izkaže, da izvirajo iz Slovenije. Spletne in e-poštne goljufije so kaznivo dejanje, ki se preganja po uradni dolžnosti. Če je storilec iz tujine, je žal pot pravice pogosto preveč trnava.
Proti 'socialnemu inženirstvu' (goljufijam) pomaga predvsem ozaveščenost uporabnikov. Do neke mere pomagajo tudi protismetni in protivirusni filtri in preverjanje domene s podpisom DKIM (google.com, yahoo.com, amazon.com, paypal.com, ebay.com in tudi ijs.si), a nekaj tovrstne pošte se vseeno izmuzne avtomatskemu preverjanju.
Zakaj dobivam obvestila o nedostavi za sporočila, ki jih nisem poslal?
Kadar si kdo 'izposoja' poštni naslov IJS in razpošilja spam/smetje v našem imenu in ga prejemnikov poštni strežnik ni pripravljen sprejeti (bodisi zaradi vsebine ali zaradi neobstoječega prejemnikovega naslova ali težav pri dostavi), se prejemnikov strežnik lahko odzove s pošiljanjem obvestila o nedostavi na naslov, ki ga je razpošiljalec smetja zavajajoče navedel kot pošiljateljev naslov. Podobno velja za sporočila z avtomatskih odzivnikov, denimo za obvestila o trenutni odsotnosti zaradi dopusta, ali za t. i. odzivnike challenge-response.
Prvotna spam-sporočila ne prihajajo od nas (le videti je tako na prvi pogled), sporočila o nedostavi pa so pristna (in niso spam), le da pridejo na naslov žrtve (naš naslov), ne pa v roke razpošiljalca smetja.
Uporaba tujih 'izposojenih' poštnih naslovov za pošiljanje spama ni nova. Razpošiljalcu koristi uporaba takih poštnih naslovov, ker se tako laže skrije, ker ga povratna pošta ne zanima in ker nekateri poštni strežniki preverjajo veljavnost pošiljateljevega naslova ob sprejemu in zato izmišljeni naslovi niso tako učinkoviti kot pravi, pa tudi zato, ker imajo nekateri prejemniki vpisane domene nekaterih svojih korespondentov na t.i. belem seznamu in se včasih na ta način laže izognejo nekaterim filtrom. Ta navada 'izposoje' naslovov se je v letu 2008 močno razpasla in o tem veliko poročajo in tarnajo tudi drugod.
Ker so sporočila o nedostavi (ali od avtomatskih odzivnikov) pristna, se jih težko ločiti od drugih takih DSN-sporočil (delivery status notifications). To velja še zlasti za sporočila od takih poštnih strežnikov, ki ne upoštevajo standarda o obliki DSN-sporočil (RFC 3462, RFC 3464) in pošljejo obvestilo kar v neki svobodni obliki. Če bi DSN-sporočila blokirali neselektivno, bi tvegali izgubo nekaterih zares upravičenih sporočil o nedostavi.
Od 4. aprila 2008 pri vsakem prejetem sporočilu DSN, ki je v standarni obliki (ali vsaj v neki pogosti in prepoznavni obliki), pregledamo priloženo glavo sporočila, na katero se DSN nanaša. Če se DSN nanaša (prek Message-Id) na neko sporočilo, ki je zares prišlo iz našega strežnika in je evidentirano v naši podatkovni bazi SQL, potem takšno sporočilo o nedostavi normalno dostavimo, sicer pa se zadrži. Na ta način sedaj uspemo prestreči okrog 85 odstotkov tistih sporočil DSN, ki so posledica 'izposoje' IJS poštnih naslovov za razpošiljanje smetja, hkrati pa ne tvegamo izgube pomembnih sporočil o nedostavi.
Žal za sporočila DSN v nestandarni obliki brez ustrezne priponke ni mogoče ugotoviti, ali se zares nanašajo na sporočilo z IJS ali le na kak ponaredek, zato tudi taka sporočila zaenkrat dostavljamo prejemniku, da bi se izognili tveganju izgube kakšnega pomembnega zavrnitvenega sporočila. Žal je tovrstnih sporočil občasno še vedno veliko kadar naš naslov spet pride na vrsto za zlorabljanje.
Pogoj za pravilno delovanje tega razločevalnega postopka v našem filtru je, da je vsa pošta, ki nosi pošiljateljev naslov iz domene ijs.si, tudi zares poslana prek našega poštnega strežnika (bodisi iz notranjih omrežij ali od domačih in potujočih uporabnikov na podlagi avtentikacije ob oddaji pošte). To je torej dodatni razlog za oddajo pošte le prek strežnika IJS - glej zgoraj pod točko: Pošiljateljev naslov in pripadajoči strežnik.
Dolgoročna rešitev je v preverjanju pristnosti pošiljatelja na poštnih strežnikih prejemnikov, preden se odločijo za pošiljanje DSN. Nekaj mehanizmov za to že obstaja (DKIM, DomainKeys, SPF, Sender ID, BATV, ...). Pri nas podpisujemo odposlana sporočila z elektronskim podpisom DKIM (RFC 4871) tako kot na primer Gmail, Cisco, eBay, PayPal (in Yahoo, ki uporablja starejšo različico tega standarda). Učinek teh mehanizmov bo bolj opazen v naslednjih letih, ko bo znatnejši del poštnih strežnikov pri prejemnikih podpiral in uveljavljal te obrambne mehanizme.