Man koopt 300 emoji-domeinnamen en bouwt emoji-e-maildienst uit

De Britse full-stack developer Ben Stokes kocht eind vorig jaar de rechten van 300 emoji-domeinnamen op waarmee hij een emoji-maildienst opzette. Met zijn dienst, genaamd Mailoji, kan iedereen tegen betaling een emoji-mailadres kopen.

Geheel toevallig ontdekte de Britse full-stack developer Ben Stokes eind 2020 dat hij naast traditionele domeinnamen ook emoji-domeinnamen kon kopen. Licht teleurgesteld kwam hij te weten dat de rechten op heel wat single character emoji-domeinnamen al waren opgekocht. Dit was echter niet het geval bij de brievenbus-emoji in combinatie met het .ws-top-level-domein, dat hij vervolgens kocht.

Stokes’ nieuwsgierigheid was niet in te dammen. De man vroeg zich af of hij zijn nieuwe emoji-domeinnaam ook kon gebruiken voor mailverkeer en daar stuitte hij op een probleem. Stokes wilde elke mail die arriveerde op het emoji-mailadres automatisch laten doorsturen naar zijn persoonlijke Gmail-account, maar dat bleek niet te lukken. Hij leerde dat emoji-mailadressen systematisch geblokkeerd worden door spamfilters en dat elke e-mail die hij van zijn nieuwe emoji-mailadres verstuurde, niet aankwam.

Om dit probleem te verhelpen liet Stokes alle mailverkeer van zijn emoji-domeinnaam automatisch doorsturen naar een conventioneel .com-mailadres waar geen emoji-spamfilter op geactiveerd stond. Vervolgens liet hij dit e-mailadres de ontvangen mails forwarden naar zijn gebruikelijke mailadres om ze te kunnen lezen. Zijn omleiding werkte en het plan rees in Stokes' gedachten om een heuse emoji-e-maildienst uit te bouwen aan de hand van hetzelfde principe.

Stokes kwam intussen te weten dat het Kazachse top-level-domein .kz de meeste single character emoji-domeinnamen nog steeds beschikbaar had, in tegenstelling tot andere tld’s. Hij kocht vervolgens alles op wat hij wilde en 1200 dollar later waren 150 Kazachse single character emoji-domeinnamen van hem, waardoor hij kon beginnen met het uitbouwen van zijn geliefkoosde e-maildienst. Met wat programmeerwerk knutselde Stokes in enkele weken tijd de maildienst Mailoji.com in elkaar waarbij alle inkomende mails van de emoji-mailadressen naar een gekoppeld mailadres worden doorgestuurd. Mails verzenden of ontvangen verloopt volgens de website voorlopig ook via het gekoppelde mailadres. Het is niet duidelijk of dit in de toekomst zal veranderen.

IT-banen

Reacties (88)

GertMenkel

Internet

14 maart 2021 13:00

Hoe leuk dit idee ook is, het nadeel van deze dienst is dat het de .kz-TLD gebruikt om de emoji te gebruiken in een webadres. Een van de eisen van die TLD is dat alles dat ermee verbonden is in Kazachstan draait, een land dat eerder al probeerde al het HTTPS-verkeer in het land door de overheid te laten onderscheppen. Als je deze dienst afneemt, ben je dus óf afhankelijk van de turbo-Grapperhausen van dat land óf de dienst kan spontaan afgepakt worden van zijn huidige eigenaar vanwege het niet voldoen aan de nodige beperkingen.

De meeste TLD's staan dit soort unicode-trucs niet toe vanwege aanvallen waar bepaalde unicode-karakters (bijvoorbeeld de cyrillische a) erg lijken op het Latijnse alfabet, waardoor je bijvoorbeeld [url="http://аррӏе.com"]аррӏе.com[/url] vs apple.com kunt krijgen. In Firefox werken deze beide links nog steeds, met alle phishinggevaren van dien. Ook is de standaard die de emoji toestaat in domeinnamen nog niet zo oud als degene die andere niet-Latijnse karakters in domeinnamen toestaat, waardoor veel registrars dit ook nog niet implementeren ook al is het technisch toegestaan.

Als laatste is het zoals altijd weer bar slecht gesteld met de ondersteuning van mailstandaarden, onder andere degene die unicode toestaat in je persoonlijke adres. Veel websites doen domme validatie op een mailadres en als ze je mailadres met een emoji al accepteren, is het alsnog vaak onmogelijk om hun systemen de mail daadwerkelijk te laten sturen. Officieel ondersteunt email vanaf het begin al quotes, spaties en comments in een mailadres, maar zie maar eens een website te vinden die dat accepteert.

Onder de streep is het dus een leuk idee voor wat social media exposure en een geinig project, maar ik zou er nooit een cent voor betalen om alle praktische- en privacyproblemen die dit oplevert.

Edit: bijkomend nadeel voor de KZ TLD is dat die twee letters in Duitsland nogal worden geassocieerd met concentratiekampen. Daar kan Kazachstan weinig aan doen en dat zullen de mensen buiten Duitsland ook wel niet weten, maar wellicht dat je fancy ⭐.kz-emailadres niet echt in de smaak valt in Duitsland...

[Reactie gewijzigd door GertMenkel op 24 juli 2024 18:57]

Gotiniens

@GertMenkel • 14 maart 2021 13:37

Je vergeet dat de @ in je localpart mag zitten. Zie: https://tools.ietf.org/html/rfc3696 pagina 5

japborst @Gotiniens • 14 maart 2021 15:15

Aai, die wist ik ook nog niet! Splitten op @ en de eerste (of laatste) match pakken gaat dus niet helemaal op.

Weet iemand een goede regex die wel compleet voldoet aan de standaarden en kan checken of het een valide email adres is? Of zal je met hard-coded lijsten moeten werken, om zo alle TLDs te ondersteunen? Schaalt alleen verschikkelijk...

GertMenkel

Internet

@japborst • 14 maart 2021 15:34

Ik geloof dat het format voor emailadressen niet regulier is, dus gaan reguliere expressies je niet helpen. Wat wel werkt is een input met type="email", dan doet de browser het voor je. HTML5 heeft voor een groot deel van de validatie gelukkig helemaal geen javascript nodig, al is een (te) groot deel van de frontendontwikkelaars daar niet van op de hoogte.

Splitten op @ kan, als je maar de laatste groep pakt als domein. In het domeingedeelte mag namelijk geen @ zitten. Let wel dat een mailadres ook mag eindigen op een IP-adres, zowel v4 als v6, of een hostname zonder TLD. Die laatste kun je waarschijnlijk negeren aangezien hostnames zonder TLD doorgaans alleen intern nuttig zijn, natuurlijk.

Wat ik van een talk over de emailstandaarden heb meegenomen is dat je beter maar gewoon probeert de mail te sturen, het is de enige echte valide manier die simpel te bouwen is die ik ken. Geen enkele Javascript-mailparser die ik gezien hebt ondersteunt de standaard volledig. Quotes en escapes werken amper.

Het zou een hoop gezeik schelen als alle velden die email voor je checken een knopje hebben van "nee, dat mailadres klopt wel, negeer de foutmelding". als je daarop klikt nadat je je mailadres twee keer hebt ingevuld ter validatie, is het echt je eigen schuld als je het dan nog fout hebt. Ik heb formulieren gezien waar dingen als de + of . of zelfs simpele getallen niet mogen. Dan heb je ook nog bedrijven als Samsung waar je geen mailadres voor je account mag gebruiken met Samsung in de naam. Mailadres+samsung@gmail.com werkt dus niet, een truc om de herkomst van je spam mee terug te vinden. Gelukkig werkte smasung wel gewoon

[Reactie gewijzigd door GertMenkel op 24 juli 2024 18:57]

supersnathan94

@GertMenkel • 14 maart 2021 17:30

Het kan wel hoor. Email validatie dmv reguliere expressie. Het probleem is alleen dat de RegEx dan 4 a4 lang is.

Voor normale gevallen voldoet deze:

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(??:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(??:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

Die dekt 99,99%
https://emailregex.com/

Edit: tweakers moet z’n emoji regex even op orde krijgen

[Reactie gewijzigd door supersnathan94 op 24 juli 2024 18:57]

GertMenkel

Internet

@supersnathan94 • 14 maart 2021 17:42

Ha, die laat precies het probleem zien, emoji valideren niet met die regex. Evenals LéonVanZantem@gmail.com niet valideert (naam van zo'n online random person generator gepakt). Okee, dat heeft te maken met UTF-8, maar toch. Contact zoeken met de Russische Google wordt er ook lastig mee, want info@яндекс.рф valideert ook niet (en daar zitten niet eens rare tekens in het localpart!). Je moet dus zelf eerst domeinen omschrijven naar punycode eer je regex werkt, en dikke kans dat je dat niet doet als je zomaar een regex van internet plukt.

Voor normale getallen gebruik je <input type="email"> en ben je van het probleem af, geen gedoe. Of je pakt een library die wel de hele RFC ondersteunt, daar zijn er genoeg van te vinden op NPM en de andere package managers. Ik zie de obsessie die mensen met Regex hebben niet zo, het is een handige tool voor simpele matching, maar in zo'n geval is echte validatie toch veel makkelijker?

[Reactie gewijzigd door GertMenkel op 24 juli 2024 18:57]

Vihaio @GertMenkel • 14 maart 2021 21:32

Op de pagina waar @supersnathan94 de regex vandaan heeft staat ook de regex die <input type="email"> gebruikt.

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

Dus met die input gebruik je onder water alsnog een regex en die regex heeft ook de problemen die jij beschrijft en ondersteund nog minder karakters.

Die pagina linkt ook naar deze pagina met daarin een goede uitleg waarom die 99%-regex of de input-regex goed genoeg kunnen zijn.

GertMenkel

Internet

@Vihaio • 14 maart 2021 22:15

Ik heb de pagina ook gelezen en de 99% regex faalt op dezelfde manieren.

Ik vind het nogal wat om te zeggen als applicatiebouwer "als jouw mailadres niet uit Latijnse tekens bestaat, rot je maar op naar de concurrent". Helemaal als er meer dan voldoende technische oplossingen bestaan die wel gewoon goed werken. De missende procentpunt van de regex is exact waarom emailadresvalidatie zo vaak mis gaat, en daarom is die 99% eigenlijk gewoon een 0% met marketing.

Dit soort onzin is de reden waarom mensen hun eigen naam (mét accenten en trema's) niet kunnen gebruiken in mailadressen. En in Nederland laat je dan voor het gemak de echte letters even weg, in Korea en Japan moet je een heel ander schrift gaan leren om iets simpels als email te kunnen gebruiken.

supersnathan94

@GertMenkel • 15 maart 2021 09:34

Ik vind het nogal wat om te zeggen als applicatiebouwer "als jouw mailadres niet uit Latijnse tekens bestaat, rot je maar op naar de concurrent".

Ja alleen doe die concurrent het niet veel beter. Soo je hebt eigenlijk geen keuze.

Het zou goed zijn voor de markt als er voor e-mailadressen (en dus ook domeinen) echt een standaard komt die makkelijk te valideren is en wel 100% de lading dekt zodat er geen implementatie verschillen zijn over tig jaar.

Zyppora @GertMenkel • 15 maart 2021 10:11

https://www.kalzumeus.com...mers-believe-about-names/

Mensen wiens naam afwijkt van de email norm kunnen sowieso niet hun eigen naam gebruiken. Je kunt wel zeggen dat het 'nogal wat' is om mailadressen die buiten de 99% vallen bij de deur te weigeren, maar dat is simpelweg een economisch besluit. Ja, je kunt tijd en dus geld steken in die laatste %, maar is dat het waard? Ga je lopen hannesen om die 1 of 2 extra klanten te kunnen meepikken die een zwaar afwijkend mailadres hebben? Ik vind het zelf nogal wat om koste wat kost 100% dekking te krijgen.

En ja, daar zijn libraries voor, waardoor het je makkelijk gemaakt wordt om de validatie te doen. Maar wat dan als je dat mailadres nog verder wilt verwerken (bijv. in een dagelijkse nieuwsbrief, of in rapportages of wat dan ook)? Gaat dat wel werken? Moeten achterliggende systemen ook aangepast worden om die afwijkende mailadressen te kunnen verwerken? Kun je die zelf aanpassen of zijn dat third-party systemen waarbij je afhankelijk bent van updates van de leverancier, en gaat die dan wel iets regelen voor jouw afwijkende dataset?

Van zaken als diakrieten en veelgebruikte karaktersets zoals Japans en Chinees mag je verwachten dat die inderdaad ondersteund kunnen worden mocht je je product/service op die markten richten, maar die ene stam in de Amazones met hun hierogliefen hoef je wat mij betreft niet te ondersteunen.

Nystran @supersnathan94 • 14 maart 2021 19:04

Ooit wilden we valideren of iets een email adres was. Uiteindelijk kwamen we uit op: bevat het een "@", dat was in ons (en ik verwacht in de meeste gevallen, bijvoorbeeld webshops) voldoende.

lappro @Nystran • 14 maart 2021 20:38

Volgens mij is de aanname dat er na de @ ook een . moet zijn met daar aan weerszijde nog karakters los van de @ ook nog veilig. Tenzij je een mail@localhost oid wilt toestaan. Maar dat soort mail kan naar mijn weten dan weer nooit buiten specifiek ingerichte machines gebruikt worden.

[Reactie gewijzigd door lappro op 24 juli 2024 18:57]

Nystran @lappro • 15 maart 2021 00:38

Over de punt in het email adres: Been there, tried that, dropped it.

De punt moet je echt weglaten, er zijn domeinen zoals
info@cocacola of john.doe@museum die valide zijn en in sommige gevallen gebruikt worden (als gebruikers nog niet weggepest zijn).

Een uitgebreidere check zou kunnen zijn 1+ karakters, dan @ dan weer 1+ karakters. Doel van de validatie is het controleren dat mensen niet per ongeluk hun naam of tel nummer invullen in een email adres veld. Tegen typo's of moedwillig fout ingevulde email adressen kun je weinig doen.

Wel zuur als je backend plat gaat op bepaalde adressen, maar is dit een reden om valide adressen aan de voorkant te weigeren? Let's cross the bridge when we get to it.

aikebah @lappro • 14 maart 2021 22:41

Nope, want dan mis je de localpart@ipv6adres syntax nog

P_Tingen @japborst • 14 maart 2021 20:46

De vraag is: waarom zou je willen regexen op e-mailadressen. Als het is voor validatie is er een veel simpelere manier, namelijk een code sturen naar het adres dat wordt opgegeven en door de ontvanger laten intikken. Verder geen controle nodig.

TWeaKLeGeND @P_Tingen • 14 maart 2021 21:27

Omdat dat weer een stap verder is, wil je je klant daarmee lastig vallen? Misschien wel misschien niet dat is een keuze die nog buiten controleren op een valide email format gemaakt kan worden. Als je inderdaad een controle wilt doen of het email in gebruik is en toegankelijk voor degene die regustreerd bij de dienst is regex niet nodig (maar alsnog wel van enig nut).

TLDR: Controle op valide email adres format en controle op of het adres werkzaam en van jou is zijn verschillende controles.

[Reactie gewijzigd door TWeaKLeGeND op 24 juli 2024 18:57]

McBacon @TWeaKLeGeND • 15 maart 2021 14:50

Omdat dat weer een stap verder is, wil je je klant daarmee lastig vallen?

Zo'n beetje elke decent site doet het wel op die manier, kan me niet herinneren dat ik er ooit iemand in de buurt over heb horen klagen.

Beter is gewoon een combinatie: een (simpele) regex als initiële check binnen het formulier zelf (geen @ vergeten bijv.), dan na submitten nog een keertje checken met iets als PHP's filter_var() function of een complexe regex, en als laatst ff een verificatiemail met een activatielinkje.

mjz2cool @P_Tingen • 15 maart 2021 07:28

Ik hoef bijvoorbeeld niet al mailtjes te ontvangen van een partij voordat ik me heb geregistreerd.
Dit is meer voor verificatie dat jij het bent die in wil loggen met een gebruikersnaam en wachtwoord.

wnwiigrtz @P_Tingen • 15 maart 2021 09:40

Omdat het niet altijd voor validatie is toch? Als ik bij de tandarts aan de balie sta en de assistent vraagt mij om mijn e-mailadres, dan zal het systeem waarop zij werkt vast wel valideren of het ingevulde e-mailadres correct is, mogelijk met een regex. Daarvoor hoeft niet naar mij een e-mail gestuurd te worden met een code die ik vervolgens aan haar moet geven, zodat zij in hun eigen systeem mijn e-mailadres kan opslaan.

Blokker_1999

Internet

@GertMenkel • 14 maart 2021 14:57

Het feit dat je op zijn eigen dienst geen emoji kunt gebruiken als local part is een mooi voorbeeld van validatie die niet goed gaat volgens mij.

Zoop @GertMenkel • 14 maart 2021 13:41

10 a 15 jaar geleden, wat beheer opgenomen van een bestaand bedrijf. Daar zat een gebruiker tussen die een apostrophe in het emailadres had zitten (onderdeel van zijn naam, of iets dergelijks). De standaard zou dat moeten ondersteunen, maar het werkte maar zelden (dat soort chars worden vaak ge-escaped om injectie achtige exploits tegen te gaan, afhankelijk per systeem hoe dat precies gedaan wordt, htmlspecialchars die er dan & apos ; van maakt bijv). Email validatie velden op formulieren, of zelfs het email adres verhuizen naar een anders systeem (ik dacht Plesk) ging gewoon niet. Na veel gemaar en gemor die gebruiker toch maar een nieuw emailadres gegeven.

Algemene regel voor dit soort dingen in IT, gebruikersnamen, domeinen, bestandsnamen, etc: gebruik geen speciale characters, als je onderscheiding wilt hebben, zoals een spatie, gebruik dan dashes / underscores, nooit geen extra punten, spaties, commas etc whatever. Ook al zou het officieel moeten kunnen, ergens ga je er toch problemen mee krijgen. Aan de ene kant omdat lang niet alle diensten zich 100% aan standaarden houden, aan de andere kant omdat het bewust gedaan wordt om misbruik (zoals jij ook zegt) te voorkomen.

Dit emoji verhaal doet daar, imo, gewoon nog een schepje bovenop.

[Reactie gewijzigd door Zoop op 24 juli 2024 18:57]

Keypunchie

Internet

@Zoop • 14 maart 2021 14:19

Algemene regel voor dit soort dingen in IT, gebruikersnamen, domeinen, bestandsnamen, etc: gebruik geen speciale characters, als je onderscheiding wilt hebben, zoals een spatie, gebruik dan dashes / underscores, nooit geen extra punten, spaties, commas etc whatever

In (het host-gedeelte) van een domeinnamen kan je geen underscores gebruiken.

Ook betekenen dashes in veel situaties iets (strikethrough in veel markup-talen), dus dat dashes en underscores *wel* veilig zouden zijn, waar punten dat niet zouden zijn, kun je echt niet zo generiek stellen.

Zoop @Keypunchie • 14 maart 2021 15:01

Iets te generiek wellicht ja, ik gaf wat voorbeelden, voor domeinen gelden weer bepaalde regeltjes natuurlijk.

Maar mijn punt is, het feit dat je speciale character kan gebruiken, kan je het beter nog steeds niet doen. Er gaat vast wel iets mis ergens. Hou het simpel

GrooV @Zoop • 14 maart 2021 13:55

Een punt in een e-mail adres levert echt geen probleem op hoor

FreshMaker

Internet

@GrooV • 14 maart 2021 16:01

Een punt in een e-mail adres levert echt geen probleem op hoor

@zoop werkt bij onze IT-achterwacht denk ik

Het bedrijf waar ik werk, gebruikt al sinds dag één voorletter.achternaam@bedrijfsnaam.nl (j.jansen@bedrijf.nl)
Nooit een issue.
Inlijving bij een ander 'moederbedrijf', wisseling van de ICT-wacht, nieuwe regels, nieuwe maniertjes.
De moeder gebruikt voorletterachternaam zonder puntje (jjansen@.... )

Krijg een nieuwe collega, we gebruiken tientallen diensten op basis van eerste mailadres, en maar één op het nieuwe.
Haar j.jansen werkt niet, dus zat ik een half uur aan de lijn met de medewerker, die volhield "het KAN NIET" mailadressen zijn NOOIT met een punt in de naam.
En gewoon niet verder willen ....

Uiteindelijk zijn collega erbij, een teamviewersessie en hem laten kijken in haar outlook ....

Maar nog steeds niet toegeven dat er soms iets anders kan zijn

Zoop @FreshMaker • 14 maart 2021 16:27

Roepen dat het NOOIT kan is beetje van de toren blazen ja, maar goed mogelijk dat het huidige systeem het niet kan. Ik heb het ook geroepen dat een apostrophe in de email absoluut niet kan, maar dan even de specs op zoekt, en warempel, is een legitiem character. Alleen accepteren een hoop systemen het simpelweg niet.

Eind resultaat is: het kan niet

(of het geeft problemen).

Is niet altijd een kwestie van willen (maar IT-ers kunnen inderdaad verdomd koppig zijn

)

FreshMaker

Internet

@Zoop • 14 maart 2021 18:23

Was maar een grap

Maar de stelligheid dat er géén punt in een mailnaam kon zitten had niets met koppigheid te maken, eerder met stug denken dat hij er verstand van had en ik dom zou zijn, want beveiliger

jpsch @FreshMaker • 14 maart 2021 20:37

Heb ook een punt in mijn gmail adres zitten. En het rare is, mijn vader niet.
Terwijl ik beide accounts op dezelfde manier aangemaakt heb.

P_Tingen @jpsch • 14 maart 2021 20:56

Voor Gmail adressen geldt iets bijzonders, namelijk dat punten genegeerd worden. Je vader kan dus rustig een punt in zijn gmail adres zetten. Heck, hij kan er zelfs meer inzetten. Maakt niet uit; komt gewoon aan. Probeer maar.

Andersom betekent dat ook dat je niet een mailadres mét punt in Gmail kan registreren als de variant zonder punt al voorkomt.

Ander truukje in Gmail is het gebruik van de + in je naam. De plus en alles erna, tot aan de @ wordt namelijk ook genegeerd. HenkDeVries@gmail.com verwijst dus uiteindelijk naar dezelfde mailbox als henk.de.vries@gmail.com en henkdevries+tweakers@gmail.com. Je kunt dit gebruiken door unieke mailadressen te maken. Mocht er spam op dat specifieke adres binnenkomen dat weet je gelijk de bron.

NullCrayfish @P_Tingen • 15 maart 2021 01:08

De + is leuk, maar word bizar vaak niet ondersteund gesaboteerd op registratieformulieren.
Ik heb er een tijdlang mijn missie van gemaakt om bedrijven te vertellen dat hun e-mailvalidatie niet deugt, maar het zijn er gewoon te veel.
Ziggo stelde zelfs dat ze het om voor hun moverende redenen zo ontworpen hadden. Zij moesten niets hebben van plusjes en zelfs GTLD's waren niet welkom. Soms, ook bij Ziggo destijds, wilt het dan nog weleens lonen om met de developer tools de clientside validatie een beetje te 'helpen' omdat die geen serverside tegenhanger heeft.

Gratis gmail gebruikers zijn er natuurlijk niet mee geholpen, maar een eigen domeinnaam met Catch-all werkt hiervoor een stuk beter.
bedrijf.tld@mijnnaam.nl

grimlock @GrooV • 15 maart 2021 07:53

Hij schrijft ook "nooit geen", dus altijd wel.

rob12424 @Zoop • 14 maart 2021 14:47

Dashes is nu ook niet altijd handig op Linux systemen. Het kan wel maar handig is anders

GertMenkel

Internet

@Zoop • 14 maart 2021 15:43

Eigenlijk is het natuurlijk diep triest dat speciale tekens nog misgaan anno $currentYear. Dat je ANSI-only werkte in 1985 snap ik nog wel, maar sindsdien kunnen computers toch echt wel ff een goede check maken op emails. Ik ben het niet oneens met je analyse, maar ik vind het toch jammer van onze hele sector dat dit nog steeds een probleem is.

Incompetente systemen die op hun bek gaan omdat er een quote in een mailadres zitten, zijn toch echt van de zotte. Het is niet aan de gebruiker om jou tegen je stomme code te beschermen, normaliseert je bestandsnamen maar gewoon. Ik erger me kapot aan de halve implementaties die overal gebruikt worden, helemaal bij producten van vele duizenden euro's per maand.

Als je risicomodel zo in elkaar steekt dat een quote in je emailveld een gevaar vormt, moet je toch echt even achter je oren krabben wat je allemaal aan het doen bent. Hetzelfde geldt voor gebruikersinvoer in bestandsnamen verwerken, dat is normaal helemaal nergens voor nodig. Als ik een bestand met een dubbele punt (ja, dat kan op niet-Windows) niet naar je server kan uploaden, ben ik niet degene die het verneukt heeft.

Eigenlijk zijn emoji hier iets heel moois in. Het zijn niet-asci-tekens die door gewone gebruikers in westerse landen worden gebruikt. Daarmee dwingen mensen programmeurs hier rekening mee te houden. Emoji in emails zullen gangbaarder zijn dan apostrofen, in elk geval.

Zoop @GertMenkel • 14 maart 2021 16:37

Helemaal mee eens, maar de praktijk is eenmaal anders.

Die gebruiker met de apostrophe in zijn zal ongetwijfeld vaak genoeg problemen hebben in te loggen in web-accounts die email als gebruikersnaam hanteren. Dat doet de gebruikers zelf niet fout natuurlijk, en de email spec zegt dat het character mag.

Maar ja, de meeste maken een email validator met simpele regex, als je rondgoogled, kom je dingen zoals

^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$

tegen, en die houden geen rekening met de speciale chars.

Dusja ... mijn advies blijft, probeer speciale chars te vermijden, of neem genoegen dat je gewoon ellende met een hoop systemen zal hebben. Kan je koppig doen "ja maar, dit is hun probleem, niet de mijne", maar voorlopig kan je niet verder ...

Emoji emailadressen gaan gebruiken is vragen om problemen.

GertMenkel

Internet

@Zoop • 14 maart 2021 16:40

Ik denk dat het grootste probleem dat je hier hebt met emoji niet per se het domein is, eigenlijk. De emoji in DNS is gewoon punycode, dus de meeste mailsoftware moet daar gewoon mee om kunnen gaan.

Waar ik net achter kom is dat Dovecot blijkbaar geen SMTPUTF8 ondersteunt en het ook niet van plan lijkt te zijn. Beetje jammer voor al die mensen met niet-alfanumerieke namen. Thunderbird ondersteunt het evenmin. Emoji gebruiken in het localpart van het domein is dus inderdaad duidelijk vragen om problemen, omdat zelfs bekende emailproducten hier geen aandacht aan besteden.

HollowGamer @GertMenkel • 14 maart 2021 13:20

De dienst is ook niet gratis, je kunt dus niet even testen of het werkt. Wil je meer extensies (ook maar beperkt - doen alsof het niet nodig is) en/of iconen dan ben je al iets duurder uit.

Ja, dat is de hele opzet van deze dienst, maar dan kun je in mijn ogen beter een goed domein kopen of dat geld gebruiken voor een goede maildienst. Achja, het staat leuk op sociaal media en op je visitekaartjes. De regenboog zal in deze tijd ook wel interessant zijn, dus ik verwacht wel dat ze er goed op gaan verdienen.

GertMenkel

Internet

@HollowGamer • 14 maart 2021 13:30

Ik geloof dat de beste man in zijn eerste jaar een paar duizend aan inkomsten heeft verdiend, niet genoeg om de kosten van het project mee te betalen.

Het verdienmodel is volgens mij letterlijk "staat leuk op tiktok", zoveel waarde heeft het verder eigenlijk niet. Je kunt er niet eens mail mee sturen, je kunt alleen mail forwarden naar je eigen adres.

Scriptkid @GertMenkel • 14 maart 2021 19:32

Daarvoor heb je puni code, ik heb daar jaren geleden al over een blog geschreven en hoe je het kunt detecteren en blokkeren:

https://www.tech-savvy.nl...ionalization-eai-attacks/

AutCha @GertMenkel • 15 maart 2021 08:29

Als tester is dit te leuk om te laten liggen. En ik heb mijn eerste slachtoffer in het wild al gemaakt: stichting De Wilde Ganzen die langs de deur kwam kreeg een server fout toen het meisje mijn account met raket-emoji adres wilde registreren (en moest dus terugvallen op mijn standaard spam adres).

laptopleon @GertMenkel • 15 maart 2021 09:11

Allemaal valide punten waarvan ik sommige niet kende, tot en met

Edit: bijkomend nadeel voor de KZ TLD is dat die twee letters in Duitsland nogal worden geassocieerd met concentratiekampen. Daar kan Kazachstan weinig aan doen en dat zullen de mensen buiten Duitsland ook wel niet weten, maar wellicht dat je fancy ⭐.kz-emailadres niet echt in de smaak valt in Duitsland...

Begrijpelijk, maar de vraag is hoe lang je bepaalde lettercombinaties buiten gebruik wil houden vanwege zoiets.

Laat staan dat heel de wereld zich er aan zou moeten gaan conformeren.

We moeten lessen trekken uit het verleden, maar je kunt je afvragen hoe nuttig het is dat niemand zijn kind nog Adolf durft te noemen bijvoorbeeld.

_Pussycat_ @laptopleon • 16 maart 2021 08:56

Als ja met Duitsers contact hebt is het zinvol er rekening mee te houden vanwege de foute associatie. Of het nut heeft.... Nou ja, het is nu eenmaal zo. Bij communicatie is dat wat aankomt belangrijk, en bij een @.KZ adres vraag ik me eerst een af met wie ik hier te doen heb.

WaarAnders 14 maart 2021 12:47

Ik heb de wiki er even bij moeten pakken:
https://en.m.wikipedia.org/wiki/Emoji_domain

Lijkt me niet echt handig, maar misschien ben ik te oud of mis ik iets?

Zoop @WaarAnders • 14 maart 2021 12:57

Ik snap het ook niet helemaal. Wellicht werkt het op mobieltjes, waar je altijd zo een emoji-menu bij de hand hebt (of je moet alle shortcodes voor emojis uit je hoofd kennen).

Stel ik zou in deze reply aan jouw mij emailadres willen geven, hoe doe ik dat?
Oh ik zie als ik op mijn mac rechtermuisklik doe dat ik bovenaan een menu heb voor emoji's en symbolen ... serieus nooit gebruikt. Is tocht totaal niet handig?

En laat tweakers dat toe? Ik zal het eens proberen Zoop@🍺.kz ?
Edit: blijkbaar werkt het, kan mij ook voorstellen dat dit er uit gefilterd wordt op sommige plekken (en programmas), om te voorkomen dat mensen idioot veel emojis in berichten gebruiken wat irritant kan zijn. Gaat het door alle email validatie velden om webformulieren heen? Zal me benieuwen

Leuke gimmick, maar dat gaat toch niemand serieus echt gebruiken, zeker vanwege de vage TLD's die er dan nog aan zitten, is het idee ook net-niet.

[Reactie gewijzigd door Zoop op 24 juli 2024 18:57]

Skit3000

@Zoop • 14 maart 2021 13:04

Op een Windows-machine: druk op de Win-key en punt om een emoji-menu te krijgen.

duke99 @Skit3000 • 14 maart 2021 16:58

Op een Mac ctrl+cmd+spatiebalk

sloppyfalstaff @Skit3000 • 14 maart 2021 13:20

weer wat bijgeleerd ! 😂👍🦪

Rico1984 @Skit3000 • 14 maart 2021 16:23

Hey die kende ik nog niet!! top dankje👍👌😎

Daoka @Skit3000 • 14 maart 2021 22:17

Zelf met deze optie blijft het wel omhandig natuurlijk. Het is vaak ook de vraag of je de goede heb. Zoals hier op Tweakers als ik zou zeggen smiley met tong. Is dat dan

? En dan heeft tweakers.net nog geen eens veel opties qua icoontjes. Laat staan dan dat je uit de icoontjes van de je telefoon moet zoeken. Ja typ je het kunnen ze het kopiëren of heb je een voorbeeld die je kan zoeken. Maar het echt zeggen of geschreven op papier wordt toch wel lastig.

Guru Evi @WaarAnders • 15 maart 2021 00:32

Niet alleen de input vinden, je moet dan al het juiste icoontje vinden er zijn duizenden emojis, een beetje slechtziend en er zien er een heel deel hetzelfde uit.

Als je een enveloppe vindt, welke ga je dan gebruiken, de rode, de witte, het e-mail icoontje, deze met een hartje of deze met een pijltje of deze met een postbus en een enveloppe, en dan nog ziet het er niet op alle platformen hetzelfde uit, soms is hetzelfde icoontje wit, soms geel, zwart, doorzichtig... help maar een mens en als je de verkeerde intikt, kom je ergens anders uit.

[Reactie gewijzigd door Guru Evi op 24 juli 2024 18:57]

vpm @Guru Evi • 15 maart 2021 10:58

Blinden/slechtzienden gebruiken voornamelijk Siri (want Android is nog een dingetje), waarbij alle pictogrammen een heldere beschrijving hebben. Als ik soms hoor wat de officiele betekenis is van sommige emoji's, dan gebruik ik ze behoorlijk fout.

Oh en op Windows zijn goede schermlezers, die gelijksoortige functionaliteit bieden.

[Reactie gewijzigd door vpm op 24 juli 2024 18:57]

GEi 14 maart 2021 12:47

Leuk artikel, maar mis een korte toelichting op emoji-domein, emoji-domeinnaam en emoji-maildienst. Wat moet ik mij hierbij voorstellen?

g0tanks Moderator CSA @GEi • 14 maart 2021 12:55

Een emoji-domeinnaam is bijvoorbeeld www.📭.ws en een emailadres g0tanks@📭.ws

Hoe het werkt is dat emoji's eigenlijk worden gerepresenteerd door punycode. Voor de brievenbus hierboven is de punycode "xn--ju8h" en het domeinnaam dat is gekocht is dus eigenlijk xn--ju8h.ws

Op dit moment zijn er 13 top-level domains waarvoor het kan: .cf, .ga, .gq, .la, .ml, .tk, .st, .fm, .to, .je, .gg, .kz en .ws

De man in het artikel heeft dus een heleboel emoji-domeinnamen opgekocht en er een emaildienst aan opgehangen.

Scriptkid @g0tanks • 14 maart 2021 19:35

.com ondersteund ook gewoon puni code, alleen mag het maar 1 enkle char zijn zover ik het weet,

Jaren geleden al een blog over geschreven hoe je dit gevaarlijk stuk kunt blokeren omdat spammers het perfect als een loop hole kunnen gebruiken om al je email countermeasure te omzeilen

https://www.tech-savvy.nl...ionalization-eai-attacks/

DeComponeur @g0tanks • 14 maart 2021 13:16

Meest opvallende vind ik dat de man speelt met taal en niet gekozen heeft voor Emailoji of Mailmoji. Emailmoji was uiteraard ook nog een optie geweest maar die wordt al gebruikt https://emailmoji.com/
Heb nog even gekeken maar al dat soort namen zijn al .com geregistreerd...

neeecht 14 maart 2021 12:43

demonite @neeecht • 14 maart 2021 12:49

.kz dan heh

01001000 @neeecht • 14 maart 2021 12:50

Meer

.kz

jaenster

14 maart 2021 13:30

En zo gaan we langzaam richting een taal waar we icons en pictrogrammen gebruiken. Net chinees

HKLM_ @jaenster • 14 maart 2021 13:43

Eerder terug naar de oude Hiërogliefen in de tijd van de Egyptenaren.

mae-t.net @jaenster • 14 maart 2021 13:51

Niet alleen icons en pictogrammen. Chinees zit ook tjokvol met rebussen en Japans zelfs nog wat voller (elk pictogram in de rebus kent zowel een Japanse als een Chinese uitspraak, kijk voor de grap eens naar een anime waar de namen verkeerd getranslitereerd zijn in de ondertiteling).

En 9 van de 10 pictogrammen zijn niet meer als zodanig herkenbaar dus eigenlijk moet je gewoon alles uit je hoofd leren.

Zouden onze talen die ontwikkeling doormaken dan kost dat wel een paar duizend jaar, en ik zie rebussen niet vrijwillig populairder worden dan ze ooit in chattaal (pre-emoticon) waren, met bijvoorbeeld n8 voor nacht. Of m8 dat afhankelijk van de taal macht of mate kan betekenen...

[Reactie gewijzigd door mae-t.net op 24 juli 2024 18:57]

Harm_H 14 maart 2021 12:48

Leuk gedaan en ziek goed uitgewerkt. Dit is toch wel weer piek internet bubbel

.

bob@⭐.kz

Had leuk kunnen werken, maar de kz is verwarrend. Eigenlijk wil je als gebruiker iets als bob@⭐ zonder tld, maar dat kan natuurlijk niet.

Blokker_1999

Internet

@Harm_H • 14 maart 2021 14:58

Kan in principe wel, maar zal je veel meer kosten omdat je ⭐ zult moeten registreren en opzetten als tld

aikebah @Blokker_1999 • 14 maart 2021 22:59

Kan dacht ik niet... want volgens mijn kun je geen mail sturen aan localpart@tld, alleen aan localpart@host.tld of localpart@host (dus je zou het wel lokaal kunnen gebruiken).
bob@🌜.⭐️ zou wel haalbaar zijn.

deadinspace @aikebah • 15 maart 2021 11:32

localpart@tld is een prima geldig e-mail adres, dus in principe zou dat gewoon kunnen.

(om precies te zijn, het is toegestaan volgens de grammatica in RFC 2822; domain -> dot-atom -> dot-atom-text -> atext -> "tld")

Of software het leuk vindt is een tweede. Er bestaat heel veel slechte en incomplete mail-adresvalidatie in de wereld, zie ook de verschillende discussies hier

aikebah @deadinspace • 15 maart 2021 19:59

Dacht dat domain in de standaarden minstens 2 dot separated parts moest hebben, maar inderdaad

A domain (or domain name) consists of one or more dot-separated components

aldus RFC 2821 die over de bezorging gaat en in 2822 daarvoor gerefereerd wordt dus alleen TLD is ook een syntactisch valide domain die zou mogen (als je de TLD owner zo gek kunt krijgen een MX record te publiceren voor de TLD)

Dank voor je correctie op mijn foute herinnering over hoe het zit.

gise 14 maart 2021 12:50

Ik mis nogal wat info in dit artikel, wat zijn bijvoorbeeld de single character emoji’s? En wat zijn dan bijvoorbeeld de domein namen die hij heeft gekocht?

Kreuk

@gise • 14 maart 2021 13:47

Single character staat er voor dat er maar 1 emoji in het domein staat. Dus 😊.kz en niet 🍄🤢.kz.
De beschikbare emoji's kan je vinden op de gelinkte site

jpsch 14 maart 2021 13:02

Zou het echt niet onder spam gefilterd worden bij de meeste mensen?

HollowGamer 14 maart 2021 13:14

Ben ik de enige die hier niet echt blij mee is? Emoji's verschillen naar mijn weten per apparaat/OS (+ versie) en ik dacht zelfs per browser, m.a.w. een gebruiker kan zich daardoor snel(ler) vergissen of andere fouten maken. Moet ik straks bijvoorbeeld ook gaan vragen of iemand 🚀.gg bedoeld of echt raket.gg? Of gaan we straks voor elke emotie een icoon gebruiken? Met een raket valt het overigens wel mee, maar met gezichten word het al een stuk moeilijker vind ik en mogelijk ontbreekt er dus een icoon op je apparaat.

Ik vind dat emoji's echt wel iets toevoegen in communicatie, maar niet om adressen aan te geven. Dat vind ik ook van domein-extensies zoals info@nl.apple/info@nl.microsoft t.o.v. info@apple.nl/info@microsoft.nl. Nee, voor mij mag deze dienst snel verdwijnen, sorry.

rob12424 14 maart 2021 13:44

Zou dit in Japan aanslaan? Die zijn toch altijd dol op dit soort dingen?

Op dit item kan niet meer gereageerd worden.

Man koopt 300 emoji-domeinnamen en bouwt emoji-e-maildienst uit

Lees meer

IT-banen

Reacties (88)

Sorteer op:

Weergave: