E-mail

De waarheid over e-mail

E-mail is een goed ingeburgerd communicatiemiddel voor particulieren en bedrijven. Wel is te zien dat particulieren, in tegenstelling tot enkele jaren gelden, onderling nauwelijks nog e-mailen. E-mails ontvang en stuur je thuis vooral naar bedrijven en hebben vaak een wat formeler karakter dan de populaire berichtendiensten zoals onder andere WhatsApp en iMessage.

Binnen en vooral tussen bedrijven is e-mail de standaard en heeft de fax uit de (meeste) kantoren verdrongen. E-mail wordt vaak te pas en te onpas ingezet voor ondersteuning van processen. Het e-mail protocol heeft ten opzichte van andere technieken echter wat nadelen waarvan men zich vaak niet voldoende bewust is. Ook wordt e-mail veelvuldig gebruikt voor spam en malware distributie. De oplossingen die daar weer tegen geïmplementeerd zijn veroorzaken ook weer uitdagingen. Al met al tijd om eens uit de doeken te doen hoe e-mail werkt en wat de beperkingen zijn op het gebied van betrouwbaarheid en beveiliging en hoe deze op te lossen zijn.

RFC780 – Simple Mail Transfer Protocol

De eerste definities van e-mail zijn terug te vinden in RFC 772 uit 1980, wat uiteindelijk geresulteerd heeft in het SMTP protocol volgens RFC 821 in 1982. De laatste update, en nu de primair gebruikte definitie uit 2008, is te vinden in RFC 5321. Laten we niet te veel op technische details proberen in te gaan, maar wel op zaken die van invloed zijn op de toepassingsmogelijkheden van e-mail.

Time-outs

In de RFC’s wordt bijvoorbeeld vastgelegd wat e-mail servers bij een afleverprobleem moeten doen. Aflever problemen komen voor omdat er bijvoorbeeld geen verbinding met de ontvangende mail server mogelijk is of omdat deze aangeeft overbelast te zijn. Vastgelegd is dat de servers dan met pauzes van minimaal 30 minuten opnieuw proberen de e-mail af te leveren, voor een periode van minimaal 4 tot 5 dagen. Pas daarna krijgt u als afzender bericht dat het afleveren niet gelukt is. Afhankelijk van de mailserver waarop het bericht is blijven hangen krijgt u tussendoor wel al een vertragingswaarschuwing (Delay Notification) conform RFC 3461.

Dit maakt dat e-mail niet geschikt is voor tijdsgevoelige communicatie. Toch zien we het regelmatig dat e-mail wordt misbruikt voor (semi-)realtime processen zoals het plaatsen van opdrachten. In een logistiek just-in-time proces gaat dat dus vroeg of laat een keer mis.

Beveiliging

Op basis van bovengenoemde RFC is de communicatie tussen e-mail clients (MUA’s) en e-mail servers (MTA’s) niet versleuteld. Een client verstuurd alle e-mail dus zonder versleuteling naar zijn server. Deze server slaat de e-mail (tijdelijk) op en verstuurd deze weer zonder versleuteling verder naar de volgende server, conform MX-records of eventuele andere routing aanwijzingen. Dit gaat zo door tot de e-mail op de eindbestemming is afgeleverd. In vergelijking met de traditionele post kun je een e-mail dan ook het best vergelijken met een ansichtkaart. Iedereen die hem in handen krijgt of zelfs maar ziet liggen kan de inhoud lezen.

Met RFC 3207 is hiervoor in 2002 Transport Layer Security (TLS) als uitbreiding voor het SMTP protocol toevoegt. TLS kennen we ook van SSL en zorgt ervoor dat een client en een server (of 2 servers) voor een sessie een encryptiesleutel afspreken. Vervolgens wordt de data (in dit geval e-mails) versleuteld verstuurt. Hierdoor kan er niemand meer tijdens het transport meelezen. Op de e-mail server staat de e-mail echter weer gewoon zonder versleuteling. Helaas wordt TLS nog niet door alle servers en providers ondersteunt. Ook kun je niet terug zien of er op de route via verschillende e-mail servers altijd gebruik gemaakt is van TLS.

Ondanks TLS kan iemand die toegang heeft tot een van de e-mail servers op de route de e-mail daar dus wel gewoon meelezen of zelfs aanpassen.

Ook hiervoor bestaan weer oplossingen. Zo is het mogelijk om e-mail te voorzien van een handtekening op basis van een certificaat. Met deze handtekening kan de ontvanger vaststellen of een e-mail gemanipuleerd is. Maar dan moet je dus wel afspreken dat de ontvanger jou e-mails alleen serieus mag nemen als er een geldige digitale handtekening in zit.

Als je helemaal wil voorkomen dat je e-mails door onbevoegden worden gelezen, dan kun je terugvallen op standaarden zoals PGP (Pretty Good Privacy). Je wisselt dan met de ontvanger van je e-mail eerst een (encryptie)-sleutel uit, waarna je de inhoud van je e-mails op een dusdanige manier kunt versleutelen dat alleen de beoogde ontvanger de e-mail weer leesbaar kan maken.

Misbruik

Toen e-mail bedacht werd aan het begin van de jaren 80 heeft men weinig rekening gehouden met het fenomeen dat we nu kennen onder de naam spam. Spam is het ongevraagd sturen van e-mail aan grote hoeveelheden ontvangers. Dit is het best te vergelijken met ongeadresseerd reclamedrukwerk, met dat verschil dat het nog goedkoper is om te versturen. Gelukkig is er ondertussen wetgeving die het versturen van spam verbiedt, echter een hoop verzenders zitten buiten Nederland en zijn daarom moeilijk tot niet te vangen.

Spam versturen is goedkoop, maar niet gratis. De organisaties die zich hiermee bezig houden doen dit omdat ze er geld aan verdienen. Dat kan op 2 manieren: er zijn genoeg mensen die reageren op de reclame en iets kopen bij de opdrachtgever van de spammer, of door het reageren op de e-mail (het openen/bekijken kan al genoeg zijn) weet de verzender data over jou te verzamelen die hij vervolgens weer kan verkopen. Denk hierbij aan je IP adres, het besturingssysteem op je computer of bij welke provider je zit.

Met verschillende lapmiddelen zoals spam-filters, SPF, DKIM en DMARC wordt geprobeerd onze postvakken spam vrij te houden. Deze technieken maken e-mail een stuk complexer dan bedoeld en ondermijnen daarmee dan ook weer de betrouwbaarheid en stabiliteit.

Adviezen

E-mail gaat nog wel even mee, maar er zijn wel wat zaken die je kunt aanpakken om de kans dat je voor onaangename verrassingen komt te staan te verkleinen.

Gebruik e-mail daar waar e-mail geschikt voor is, dus niet voor realtime communicatie en bijvoorbeeld ordersystemen. In plaats daarvan kunnen web services (api’s) ingezet worden om veilig (via HTTPS) en met directe terugkoppeling gegevens uit te wisselen met leveranciers, afnemers en machines.

Maak bij het versturen van persoonsgegevens altijd gebruik van encryptie. Dat kan bijvoorbeeld ook door het bestand te comprimeren met ZIP en van een wachtwoord te voorzien. Dat wachtwoord stuur je dan via een andere kanaal (bijvoorbeeld SMS) naar de ontvanger.

Inventariseer de e-mailstromen van je bedrijf. Vaak worden er vanuit een contactformulier op de website ook e-mails verstuurd, waar vaak persoonsgegevens in zitten. Laat dit aanpassen, zorg dat je alleen nog een notificatie krijgt en ga de informatie via een veilige (HTTPS) verbinding ophalen op de webserver.