Sähköposti
Sähköpostin osoitteisiin liittyvä @-merkki.
**Sähköposti** tarkoittaa digitaalisten, yleensä kirjallisessa muodossa olevien viestien välittämistä tietokoneilla nimetyille vastaanottajille. Viestit säilötään lukemista varten.
Viestit välitetään tietyillä protokollilla useimmiten tietoverkkoon vähintään postin lähettämisen ja noutamisen ajaksi kytkeytyvien tietokoneiden välillä. Sähköposti on nopea ja helppo tapa tavoittaa vastaanottaja. Sähköpostia käytetään myös henkilökohtaiseen tiedostojen tallentamiseen ja varmuuskopioimiseen. 

Sähköpostia välitetään Internetissä tietokoneiden välillä SMTP-protokollan avulla.
Sähköposti luetaan asiakasohjelmalla, joka voi olla tietokoneen työpöytäohjelma tai selaimessa pyörivä web-sovellus.
Asiakasohjelma hakee sähköpostin palvelimelta POP3 ja IMAP-protokollalla, joita melkein kaikki sähköpostiohjelmat tukevat.

Historiaa
---------

Sähköposti oli olemassa ennen tietoverkkoja. Varhaisiin keskustietokoneisiin oli kytkettyinä usea pääte ja niitä voi käyttää usea käyttäjä. 1960-luvulla kehitettiin sähköpostijärjestelmiä, joilla toisille koneen käyttäjille voi lähettää viestejä. Tenex-käyttöjärjestelmässä oli käsky SNDMSG, joka lähetti viestin toisen käyttäjän hakemistoon tiedostoon nimeltä MAILBOX. Postin voi lukea tulostamalla tiedosto ja poistaa editoimalla sitä tekstieditorilla. Käyttäjän kirjautuessa järjestelmään se ilmoitti jos käyttäjälle oli tullut sähköpostia. SRI Internationalin Dick Watson ehdotti 1971 "Mail Box Protocol" -määritelmää (RFC-196), jolla dokumentteja voisi lähettää kaukokirjoittimella tai muulla kirjoittimella tulostamista varten. BBN:n Ray Tomlinson piti tätä turhana ja halusi käyttäjän päättävän dokumentin tulostamisesta. Tomlinson kehitti ohjelman, jolla tiedoston voi kopioida toisen käyttäjän postilaatikkoon eri koneella Arpanetin yli. Tomlinson päätti myös käyttää @-merkkiä yhdistämään käyttäjän ja tietokoneen nimi. Näin user@remote oli sähköpostiosoite verkossa.

ARPA:n johtaja Larry Robert kirjoitti ensimmäisen varsinaisen ohjelman nimeltä RD sähköpostin lukuun TECO-tekstieditorin makrokielellä. Sen avulla voi listata sähköpostilaatikossa olevat viestit, valita niistä luettavan ja printattavan. Vuoden 1973 lopulla sähköposti oli jo yleisessä käytössä Arpanetissa. Aluksi Tenexin CPYnet-tiedostonsiirto-ohjelma korvattiin FTP:llä. FTP:hen lisättiin MAIL-käsky (myöhemmin APPEND) tiedoston kopioimiseksi postilaatikkoon. Tässä vaiheessa sähköpostin muotoa ei oltu vielä standardoitu, vaan viestien välillä käytettiin neljää Control-A-merkkiä (SOH, Start of Header). Sähköpostin standardointia tehtiin jo vuonna 1973 (RFC 561): jokaisessa viestissä piti olla vähintään kolme kenttää alussa: From, Subject ja Date (lähettäjä, aihe ja päivämäärä). Tämän seuraajaksi tuli RFC-680 ja vuonna 1976 RFC-724 ja RFC-733, joka oli käytössä 1980-luvulle.

Uudet sähköpostijärjestelmät käyttävät kansainvälisiä verkkoja, kuten internet. Vuonna 1980 julkaistu RFC 771 kuvaa aiottua siirtymistä ARPANETistä Internetiin. Tuloksena syntyivät vuonna 1982 SMTP (RFC 821) viestien siirtoa varten ja sähköpostin muodon kuvaava RFC 822, joihin nykyinen sähköposti perustuu.

Nykyisin sähköpostin tietoturvaa on parannettu eri tavoin.
Vuonna 2011 määriteltiin DomainKeys Identified Mail (RFC 6376, päivitetty RFC 8301 ja RFC 8463), jonka on tarkoitus estää postin lähetys väärennetyillä osoitteilla.
Tämä on yksi kolmesta autentikaatiomenetelmästä (SPF, DKIM ja DMARC), joiden on tarkoitus estää väärennetyt viestit.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) lisää DNS-nimipalveluun ohjeet, miten vastaanottaja voi autentikoida tulevan sähköpostin, joka väittää tulevansa määrätystä verkkotunnuksesta.

SPF (Sender Policy Framework, RFC 7208) listaa nimipalvelussa verkkotunnuksen sallitut isäntänimet ja IP-osoitteet, joista sähköpostia lähetetään.

Näiden käyttö on nykyisin lähes pakollista, sillä Google alkoi vaatia DKIM:in käyttöä Gmailiin lähetettävistä massaviesteistä helmikuussa 2024.

Ohjelmat
--------

Sähköpostin käsittelyyn liittyviä ohjelmia ovat asiakasohjelma, jolla käyttäjä lukee sähköpostia (*Mail User Agent*, MUA), välitysohjelma (*Mail Transport Agent*, MTA) ja palvelinohjelma (*Mail Delivery Agent*, MDA).

Asiakasohjelma (MUA) käsitetään sähköpostin lähteenä ja kohteena: asiakasohjelma antaa sähköpostin välitysohjelmalle (MTA) (RFC 5321). Palvelinohjelma kerää viestit ja odottaa käyttäjän hakevan viestit asiakasohjelmalla.
MTA-ohjelmat käyttävät SMTP-protokollaa ja siksi kutsutaan usein SMTP-palvelimiksi ja MDA-ohjelmia kutsutaan POP- ja IMAP-palvelimiksi.

Havainne sähköpostiohjelmista.Havainne sähköpostiohjelmista.

Sähköpostin edut
----------------

Sähköposti on nopea, edullinen ja vaivaton viestintätapa. Tavalliseen kirjeeseen verrattuna suurin etu on sen nopeus. 

Sähköpostiviesti menee perille sekunneissa tai muutamassa minuutissa maapallon toiselle puolelle, yleensä Internet-verkkoa hyväksi käyttäen. Sähköposti voidaan saada myös sinne, minne Internet ei ulotu, esimerkiksi hakemalla ja lähettämällä viestit puhelinyhteyden kautta, kuten aikoinaan ennen Internetin yleistymistä.

Kustannuksiltaan sähköposti on huomattavasti tavallista kirjettä halvempi. Käyttäjä maksaa usein vain internetyhteyden tietokoneellensa. Verkkoyhteyden ei tarvitse olla auki kirjettä kirjoitettaessa, vaan viestin voi laatia valmiiksi ennen yhteydenottoa sähköpostipalvelimeen. Kun kirje on valmis, otetaan yhteys verkkoon, lähetetään viesti vastaanottajalle ja haetaan samalla mahdolliset itselle osoitetut viestit; yhteys ei näin usein kestä minuuttiakaan. Tietokoneella oleva ohjelma voi tehdä tämän automaattisesti aina yhteyden syntyessä, mikä on kätevää myös kannettavilla tietokoneilla. Tavalliseen kirjeeseen verrattuna käsittelykustannukset jäävät pieniksi: kopiointia, kirjekuoria ja postimerkkejä ei tarvita, eikä kenenkään tarvitse edes nousta pöytänsä äärestä.

Puhelimeen verrattuna sähköpostin etu on vastaanottajan saavutettavuus. Vaikka vastaanottaja ei olisikaan heti tavoitettavissa, sähköposti voidaan lähettää odottamaan. Kun vastaanottaja tarkastaa postilaatikkonsa, on sähköposti odottamassa häntä.

Sähköposti on myös helppo tallentaa ja tarkistaa jälkikäteen.

Sähköpostin lukumahdollisuus on lisätty myös mobiililaitteisiin ja matkapuhelimiin sekä älypuhelimiin ja taulutietokoneisiin. Tähän liittyen on kehitetty Push Email.

Ongelmat
--------

Sähköposti kulkee verkossa yhä usein selväkielisenä, ellei viestiä erikseen salata. Salatunkin viestin "kuoressa" kulkevat tiedot (lähettäjä ja vastaanottaja yms.) ovat näkyvillä. Toisaalta kirjesalaisuus koskee myös sähköposteja ja verkon salakuuntelu ei onnistu helposti kuin lähiverkossa ja teleoperaattoreiden tiloissa. Salakuuntelun mahdollisuus on kuitenkin hyvä pitää mielessä, jos haluaa suojautua vakoilulta.

Suurena ongelmana on roskaposti, joka tukkii postilaatikoita mainoksilla tai muuten epätoivotuilla viesteillä. 2000-luvun alussa 75–90 % verkossa liikkuvasta sähköpostista oli roskapostia. Sähköpostia suodatetaankin eri tavoilla roskapostin torjumiseksi. Jotkut käyttävät myös ensisijaisen sähköpostiosoitteensa rinnalla toista, rajummin suodatettua osoitetta, niissä yhteyksissä, missä käyttäjä epäilee osoitteen helpoiten joutuvan roskapostaajien listoille.

Myös haittaohjelmat voivat levitä sähköpostin välityksellä. Jotta viesti näyttäisi asialliselta, haittaohjelma voi lisätä viestiin tietokoneelta löytämiään, mahdollisesti salassa pidettäviä tai arkaluonteisia, asiakirjoja. 

Joskus sähköpostiviesti voi hävitä, joko väärin säädetyn palvelimen asetusten tai liian tiukan roskapostisuodattimen takia. Tämä on kuitenkin epätavallista, ellei viesti ole huolimattomasti laadittu, niin että se muistuttaa roskaposteja. Mahdollisia omia roskapostisuodattimia kannattaa säätää varovasti, etteivät ne hävitä postia.

Eräs ongelma on myös vastaanottajan osoite. Osoitteen on oltava tarkasti oikein, jotta viesti saavuttaa vastaanottajan. Väärin kirjoitettu osoite johtaa yleensä viestin palauttamiseen lähettäjälle (kunhan lähettäjätiedot ovat kunnossa), ellei käytetty osoite kuulukin toiselle henkilölle. Sähköpostiohjelmissa on yleensä tuki osoitekirjalle ja muille tavoille hakea osoite automaattisesti, jolloin kirjoitusvirheet vältetään. Sähköpostiosoite lisätään usein käyntikorttiin tai kirjelomakkeeseen.

Pitkissä, useiden ihmisten välisissä keskusteluissa ongelmaksi muodostuu vaihtelevat tavat lainata aiempia viestejä. Joidenkin mielestä erityisesti top-postaus on häiritsevää, koska se vaikuttaa keskustelun seuraamiseen. Top-postaaminen voi myös olla tietoturvariski, jos viesti lähetetään eteenpäin kaikkine aiempine lainauksineen näitä tarkistamatta.

Sähköpostin rakenne
-------------------

Sähköpostiviesti alkaa otsaketiedoilla (engl. *header*), joissa kerrotaan lähettäjä ja vastaanottaja, viestin aihe, viestin muoto (tekstin koodaus, onko liitteitä jne.), onko viesti vastaus toiseen yms. Näitä seuraa tyhjä rivi, jonka jälkeen tulee itse viesti. Jos viesti koostuu useammasta osasta (esimerkiksi jos siinä on liitteitä), jokaista osaa edeltää vastaavasti ryhmä otsakkeita, jotka kuvaavat kyseistä osaa. Sähköpostiohjelma näyttää näistä tiedoista vain sen, minkä tulkitsee oleelliseksi, ellei erikseen pyydä kaikkea näkyville. Jotkut ohjelmat myös esittävät otsakkeiden nimet käyttöliittymän kielelle käännettyinä.

Sähköpostimaailma on vielä paikoin 7-bittinen, joten mahdolliset ASCIIhin kuulumattomat merkit pitää koodata ainakin otsaketiedoissa. Yleensä sähköpostiohjelma huolehtii tästä, mutta joskus näkee ääkkösten korvaantuneen kysymysmerkeillä, X:illä tms. Ääkköset sähköpostiosoitteissa voivat aiheuttaa myös ongelmia, koska useat sähköpostiohjelmat eivät ole IDN-tuella varustettuja. 

Kun viesti lähetetään palvelimen kautta maailmalle, viestiin lisätään "kuori" (katso viestinvälitysprotokolla SMTP laajennoksineen), jonka perusteella palvelimet päättelevät minne viesti pitää lähettää ja mitä tehdä virhetilanteissa. Vastaanottajan sähköpostipalvelin tallettaa viestin (ilman kuorta) vastaanottajan sähköpostilaatikkoon, jossa se on luettavissa tai noudettavissa vastaanottajan sähköpostiohjelmalla.

### Lähettäjätiedot

* From: henkilö(t) tai toimi, jonka puolesta sähköposti lähetetään; usein tämä on ainoa lähettäjätieto
* Sender: henkilö (tai robotti), joka lähettää viestin, jos muu kuin yllä mainittu tai kun viesti lähetetään useamman henkilön puolesta; virheilmoitukset lähetetään tähän osoitteeseen
* Resent-From, Resent-Sender: jos viesti on edelleenlähetetty sellaisenaan, eikä "forward"-toiminnolla, (postituslista, väärä osoite yms.) edelleenlähettäjä kuvataan joskus näillä tiedoilla
* Reply-To: osoite, johon vastaukset halutaan, esimerkiksi silloin, kun viesti lähetetään postituslistan kautta ja vastaukset halutaan joko listalle tai itselle vastoin listan käytäntöjä, tai kun halutaan kopio toisellekin henkilölle.

Osoitekentissä sähköpostiosoitteet kirjoitetaan joko sellaisinaan tai, jos myös henkilön nimi halutaan kirjoittaa, kulmasulkeissa. Sähköpostiosoitteet ovat lähettäjätiedoissa pakollisia. Kommentteja voi kirjoittaa kaarisulkeisiin, mutta tätä ei suositella, koska jotkut sähköpostiohjelmat tulkitsevat kommentit niminä. Osoitteet erotetaan pilkulla.

```
 From: Jari Jokunen (kommentti) <jari.jokunen@example.org>,
       Matti =?iso-8859-1?Q?Meik=E4l=E4inen?= <matti.meikalainen@example.org>
 Sender: matti.meikalainen@example.org

```

Osoitekentissä ei saa olla kuin ASCII-merkkejä, miksi muut merkistöt pitää koodata, ilmoittaen merkistön ja koodauksen, tässä iso-8859-1 ja quoted printable. Lukijalle nimi näkyy oikein: Matti Meikäläinen.
Erikoismerkeille harvemmin on käyttöä, mutta niiden esittämiselle on omat sääntönsä. Tyhjällä alkavia jatkorivejä saa käyttää. Yleensä sähköpostiohjelmat hoitavat tarvittavan koodauksen, mutta joskus, varsinkin erikoisemmissa tapauksissa, koodaus voi epäonnistua.

### Vastaanottajat

* To: viestin varsinainen vastaanottaja
* CC: tiedoksi ("carbon copy", "kopio")
* BCC: tiedoksi, varsinaisille vastaanottajille ilmoittamatta ("blind carbon copy", "piilokopio"); yleensä BCC-rivin osoitteet eivät jää näkyviin kenellekään vastaanottajista

Eri vastaanottajien eron ymmärtää (humoristisella) ohjeella:

```
 To: yhteistyökumppani
 CC: johtaja
 BCC: lehdistö

```

Joskus BCC-kenttää käytetään myös silloin, kun viesti lähetetään monelle ihmiselle, jotka eivät välttämättä kaikki halua paljastaa osoitteensa muille. Oikeat sähköpostilistaohjelmat osaavat kertoa osoitteet viestin kuoressa, mikä yleensä vastaa BCC-rivin käyttöä.

Tässä käytössä on hyvä käyttää joko yhteistä osoitetta (sähköpostilistan osoite tai vastaava alias) tai tyhjää vastaanottajalistaa To- tai CC-rivillä, sen mukaan ovatko nämä henkilöt varsinaisia vastaanottajia, vai onko viesti heille vain tiedoksi:

```
 To: tukilaiset <tukilaiset@example.org>

 To: tukilaiset:;
 CC: hallitus:;

```

Vastaanottajien osoitteet voidaan lisätä BCC-rivillä, mutta näin vastaanottajat tietävät, missä ominaisuudessa he ovat saaneet viestin ja keiden muiden voi olettaa sen saaneen. Listaa voi käyttää myös silloin, kun osoitteita ei tarvitse piilottaa:

```
 To: tukilaiset: Joku <joku@example.org>, Toinen <toinen@example.org>;

```

### Aihe

Subject-rivillä kerrotaan viestin aihe. Tämä on syytä valita huolella, varsinkin jos vastaanottaja saa paljon sähköpostia. Kun viestiin myöhemmin tahtoo palata, on hyvä jos otsikko on kuvailevampi kuin "Hei". Huono otsikko saattaa myös johtaa siihen, ettei viestiä koskaan lueta.

WikisanakirjaWikisanakirjaWikisanakirjassa on tähän liittyvä sananselitys: **res**.
Kun vastataan toiseen viestiin, sähköpostiohjelma lisää viestin aiheen eteen "`Re:`", jollei sellaista jo ole. Näin alkuperäinen viesti erottuu ja viestit on helppo ryhmittää. "`Re:`" lyhenne on johdettu *latinan sanasta* res ("asiaan liittyen"), eikä yleisen harhaluulon mukaisesti englannin kielen sanasta *reply*. Joissakin sähköpostiohjelmissa tämä etuliite on lokalisoinnin nimissä käännetty eri kielille, jolloin ohjelmat eivät enää tunnista sen teknistä merkitystä, seurauksena yhä pitenevä aiherivi ja ryhmittämisen vaikeutuminen.

### MIME

Ennen vanhaan sähköpostit lähetettiin 7-bittisellä ASCII:lla ja sen kansallisilla muunnoksilla. Kun kansainvälinen sähköposti ja erilaiset liitteet yleistyivät, tämä, satunnainen uuencode ja eri yhteisöjen käytännöt eivät enää riittäneet, jolloin kehitettiin MIME ("Multipurpose Internet Mail Extensions") yhteiseksi tavaksi kuvailla viestin sisältö ja sisällön muoto. MIME on sittemmin siirtynyt käyttöön muuallekin.

#### Content-\*

Tässä saatekirje on pelkkää länsimaista, 8-bittistä tekstiä sellaisenaan, ilman sen kummempia muotoiluja. Sähköpostiohjelma saa lisätä rivinvaihtoja kappaleisiin. Tyypillinen suomalainen saatekirje, paitsi, että kuvaus "saatekirje" harvoin lisätään:

```
 Content-Description: saatekirje
 Content-Type: text/plain; charset=iso-8859-1; format=flowed
 Content-Transfer-Encoding: 8bit

```

Tässä MIME-osassa liite on mukana useammassa kuin yhdessä muodossa, esimerkiksi sähköpostiohjelmassa helposti luettavana tekstinä ja PDF:nä tulostamista varten (osien välissä rivi `"--==--=="`):

```
 Content-Type: multipart/alternative; boundary="==--=="

```

Vastaava, mutta tässä liitteen osat eivät ole saman asian vaihtoehtoisia näyttötapoja, vaan esimerkiksi saatekirje ja liite:

```
 Content-Type: multipart/mixed; boundary="==--=="

```

Tässä on kokouskutsu pdf-muodossa, tallentamiseen ehdotetaan tiedostonimeä kutsu\_syys07.pdf (joka toimii useimmissa käyttöjärjestelmissä), tiedosto on koodattu base64-koodauksella, jotta se ei rikkoontuisi matkan varrella, ja se ehdotetaan näytettäväksi liitteenä, ei suoraan:

```
 Content-Description: kokouskutsu; filename=kutsu_syys07.pdf
 Content-Type: application/pdf;
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment

```

### Tieto postin kulusta

Jokainen sähköpostipalvelin matkan varrella lisää viestin alkuun `Received`-rivin, jossa se kertoo mistä se sai viestin, oman nimensä, kellonajan ja muuta virheenetsinnässä mahdollisesti tarvittavaa tietoa. 

Viestiä edelleenlähetettäessä sellaisenaan (kuten silloin, kun oletetaan viestin olevan tarkoitettu myös toiselle, eikä selitystä tästä tarvita), viestin alkuun lisätään myös joukko Resent-rivejä, jotka vastaavat alkuperäisen viestin tietoja, mutta kertovat edelleenlähettämisestä, esimerkiksi Resent-From, Resent-To ja Resent-Date.

Viestin lähettäjän on mahdollista kirjoittaa lähettäjätiedot haluamikseen ja myös lisätä Received-rivejä viestin alkuun. Sen sijaan hän ei voi juurikaan vaikuttaa siihen, mitä viestiä vastaanottavat palvelimet siihen kirjoittavat.

Jos muka ystävältä tulleen törkeän viestin Received-tiedot poikkeavat vastaavista hänen muissa viesteissään, on aihetta olettaa, että lähettäjätiedot on väärennetty. Samaten jos muka pankilta tullut viesti on kulkenut ilmaissähköpostipalvelimen kautta (pankit *eivät* lähetä salasanapyyntöjä tms. sähköpostin kautta; jos viesti vaikuttaa uskottavalta, soita pankkiin ja kysy).

Sähköpostiohjelmat voivat myös pyytää tietoja siitä, onko viesti tullut perille ja onko se avattu. Useimmiten nämä toiminnot eivät ole käytössä, yksityisyyden suojelemiseksi. Silloinkaan, kun ne ovat käytössä, ei ole varmuutta siitä, onko vastaanottaja oikeasti huomannut viestin. Jos viestin perillemeno on tärkeää, pyydä kuittaus ja käytä tarvittaessa puhelinta.

### Viittaukset viesteihin

Sähköpostiviestissä on sitä yksilöivä tunniste,

```
 Message-ID: <jokinkoodi@example.org>

```

johon voidaan viitata muualta, esimerkiksi vastausviestin kohdissa

```
 In-Reply-To: <jokinkoodi@example.org>
 References: <aikaisempi@example.org> <jokinkoodi@example.org>

```

Näiden koodien perusteella koko viestiketju on helppo jäsentää, myös silloin, kun aihe muuttuu.

### Päiväys

Sähköpostiviestit päivää joko sähköpostiohjelma tai palvelin:

```
 Date: Fri, 26 Oct 2007 11:03:47 +0300

```

Päiväys on määrämuotoinen ja aikavyöhyke ilmoitetaan erotuksella UTC:hen, joskus sen lisäksi aikavyöhykkeen lyhenteellä. Päiväyksen on tarkoitettu osoittavan hetkeä, jolloin viesti on kirjoitettu valmiiksi, lähettämisen aika näkyy Received-tiedoista.

Katso myös
----------

* Sisällönhallinta
* Selainposti

Lähteet
-------

* Tietoviikko: Nettipokeri paljasti tuhansien suomalaisasiakkaiden yhteystiedot (Arkistoitu – Internet Archive)
* RFC 5321 (korvaa: RFC 2821) sähköpostiviestien välitystä koskeva standardi ESMTP (englanniksi)
* RFC 5322 (korvaa: RFC 2822) sähköpostiviestien muoto (englanniksi), katso myös laajennoksia koskevat RFC:t

### Viitteet

1. 1 2 3  The Technical Development of Internet Email – Internet Archive
2. ↑
3. ↑
4. 1 2 3  How Email Works (MTA, MDA, MUA) *ccm.net*. Viitattu 28.11.2020. (englanniksi)
5. ↑  Ääkköselliset verkkotunnukset ja domainpäätteet *Zoner.fi*.  23.10.2014. Viitattu 29.10.2020.

Kirjallisuutta
--------------

* Alasilta, Anja: *Meili meitä pyörittää: Työelämän sähköpostiviestintä*. Helsinki: Infor, 2009. ISBN 978-952-5123-86-9.

Aiheesta muualla
----------------

* Kuvia tai muita tiedostoja aiheesta **Sähköposti** Wikimedia Commonsissa