Sähköposti

• 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.

• 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>;

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.

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.

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.

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

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.

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.

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.