Research and Development 1/^Archief/2009-2010/15/Fase 2

Voor onszelf: Wat doen wij op deze pagina?

• beschrijven beslissing om te gaan voor een prototype dat het mailformaat hervormt mbv XML (relatie met polluitslag en inhoudelijke argumenten en voorbeelden)
• beschrijven product en ontwerpbeslissingen motiveren

---

Mailergernissen - Fase 2

Discussie oplossingen

In de enquête van fase 1 zijn de vijf grootste e-mailergernissen beslist, wat ons zou moeten helpen te bepalen wat voor oplossing we het beste kunnen bedenken voor deze ontwikkelfase. Hieronder over elk van de vijf een korte discussie:

Mogelijkheid bijlagen toevoegen te beperkt (in grootte en bestandstype)

Het blokkeren van bepaalde bestandstypen (.exe, .mdb) is gemakkelijk op te lossen, of liever gezegd gebruiksvriendelijker te maken. Nu stoppen mensen bestandjes in een zip of veranderen tijdelijk de extensie om het te kunnen versturen (als ze die mogelijkheden tenminste kennen). Handiger zou het zijn, met behoud van veiligheid, dat die bestanden weer door ontvangers gedeblokkeerd en alsnog geopend kunnen worden, met de nodig geachte veiligheidswaarschuwing. Maar dan moeten e-mailproviders wel de attachments doorsturen en daar zit precies het probleem, dat wij dus niet kunnen oplossen. Dat mailproviders geen attachments groter dan 10MB willen afleveren kunnen wij ook niks aan doen, maar aangezien er genoeg services zijn voor het doorsturen van grotere bestanden (YouSendIt, DropSend en dergelijke) zouden we kunnen kijken naar het integreren van zo'n dienst, of beter nog een standaard die elk van die diensten kan gebruiken, in een mailclient, zodat grotere bestanden versturen veel makkelijker wordt. Dit is echter niet zo makkelijk voor ons en biedt ook geen erg grote voordelen ten opzichte van de mogelijkheid naar de site van de dienstaanbieder te navigeren en daar in te loggen.

Bladeren door e-mails is lastig (veel pagina's)

Dit valt natuurlijk op te lossen bij een e-mailclient, maar is eigenlijk zinloos voor ons omdat bijvoorbeeld Outlook en Thunderbird dit probleem helemaal niet hebben. In webmailclients kan vaak worden ingesteld hoe veel e-mails op een pagina moeten worden geplaatst. Daardoor overigens wel opvallend dat zo veel mensen het als probleem zien.

Misbruik van e-mailadressen is te makkelijk

We weten eigenlijk niet zeker of mensen deze formulering wel begrepen. Het probleem waar we op doelden, is het feit dat het heel makkelijk is een e-mail te sturen met als afzender een ander adres dan het adres waar het daadwerkelijk vandaan komt, op zo'n manier dat de werkelijke afzender niet te achterhalen is. Allerlei soorten misbruik is daardoor mogelijk, spam in het bijzonder. Dit probleem valt op te lossen als mailservers hashes van alle verstuurde e-mails bewaren (hoeft niet veel geheugen te kosten, want hashes zijn niet groot en hoeven normaal niet lang bewaard te blijven). De ontvangende kant kan dan ook elke e-mail hashen en aan de (vermeende) afzender vragen of die server een e-mail met die specifieke hash heeft verstuurd. Dit geeft een goede mogelijkheid de afzender te valideren en er zijn geen sleutels voor nodig zoals bij PGP, dat niet echt van de grond is gekomen.

Ongedaan maken verstuurde mail niet mogelijk

Enkelen hebben opgemerkt dat Gmail dit wel kan, maar die functie is zeer beperkt, omdat het hier puur gaat om een verzendvertraging. Het zou regelmatig toch erg handig kunnen zijn om een verstuurde mail 'terug te kunnen roepen' zo lang hij niet geopend is. Dit zou bijvoorbeeld mogelijk zijn als mailclients geautomatiseerd deletemailtjes kunnen sturen, zodra je bij je sentbox van een mailtje aangeeft dat je hem wil terugroepen. Daarnaast moet de ontvangende server natuurlijk die 'deletemailtjes' ook kunnen opvolgen. Dit valt wel te bouwen, maar het lijkt niet realistisch dat dit idee daadwerkelijk overgenomen gaat worden door mailservers en -clients. Meerdere bedrijven moeten dit systeempje namelijk geïmplementeerd hebben, voordat het een beetje kan werken, en het voordeel is daar vast niet groot genoeg voor.

Spam

Spam is alleen maar zo moeilijk aan te pakken door bovenstaand probleem over misbruik van e-mailadressen. De oplossing lijkt ons dan ook de zelfde.

Conclusie: keuze voor development

Het ontwerpen van een afzendervalidatie lijkt het meest veelbelovende project voor ons, aangezien het twee van de vijf problemen kan oplossen en we ook zelf geloven dat er vraag naar is. Het is echter wel vrij ingewikkeld. We hebben bij de keuze ook het vrij in te vullen veld van de enquête serieus genomen, waarin de suggestie stond dat er wel een parseerbare standaard mag komen voor de e-mailopmaak. Uiteindelijk is besloten dat we daarmee aan de slag gaan en daarvoor gebruik gaan maken van het voor de hand liggende XML.

Probleemstelling

Naast plain text is er nooit een standaard aangenomen voor de opmaak van e-mails. Niet voor de inhoud (body), maar ook niet voor de manier waarop de 'vorige' e-mail van een conversatie, de mail waarop wordt gereageerd of die wordt doorgestuurd, wordt meegestuurd. De opmaak van de inhoud is een kwestie van gewoonweg afspreken dat bijvoorbeeld html dat is, maar voor het tweede probleem hebben wij nog nooit een oplossing gezien. Elke mailclient stuurt de mail waarop wordt gereageerd of die wordt doorgestuurd (hierna 'geïncludede mail' te noemen) op een andere manier door. Het enige dat standaard is, is een 'RE:' voor de onderwerpregel bij een reply en een 'FW:' voor de onderwerpregel bij een forward. De body loopt voor verschillende clients sterk uiteen. Hieronder wat voorbeelden ('real-life', niet door ons verzonnen, door Outlook uitgeprint als pdf):

Bestand:Mailvoorbeeld1.pdf
Bestand:Mailvoorbeeld2.pdf
Bestand:Mailvoorbeeld3.pdf

Er zijn veel problemen te ontdekken, die allemaal komen door twee oorzaken:

• geïncludede mail is deel van de body van een e-mail
• elke client heeft andere manieren om mail te includen

Dat eerste punt willen wij veranderd zien, dan is het tweede helemaal geen probleem meer en kan zelfs iedereen persoonlijk kiezen hoe dat includen er voor hun precies uit ziet. De problemen die hiermee worden opgelost, zijn onder andere (zie voorbeelden):

• Scheiden van verschillende geïncludede mails verschilt per afzender (horizontale lijnen ertussen, ingesprongen al dan niet met verticale lijnen of >-tekens etc.)
• Hoeveelheid informatie over geïncludede mail verschilt (soms alleen afzender en datum, soms ook tijd, subject en alle to- en cc-adressen)
• Volgorde informatie over geïncludede mail verschilt (bijvoorbeeld datum als eerste of onderwerp als eerste)
• Datumformaat verschilt
• Mailadressen als links of niet
• Soms staat er voor een geïncludede mail bijvoorbeeld "Op XX XX schreef XX <X> het volgende:", oftewel iets in het Nederlands, terwijl de ontvanger misschien wel helemaal geen Nederlands kan
• Een zoekactie die gespecificeerd is op de body van e-mails, kan verkeerde resultaten geven omdat het zoekwoord is gevonden in bijvoorbeeld een mailadres of onderwerp van een geïncludede mail

De makers van Gmail hebben ook hun best gedaan deze problemen op te lossen, door e-mails in de webmailinterface zo netjes mogelijk weer te geven en door de gebruikte 'includemanier' van de vorige afzender te kopiëren. Dit werkt echter niet perfect en zien wij sowieso als een kunstgreep. Wat Gmail doet is het bestrijden van symptomen en niet van de oorzaak. Wij willen dat wel doen, door e-mail meer semantisch te maken. We willen een functionele scheiding tussen een e-mail en een geïncludede mail, want daarmee zullen alle gevonden problemen niet meer bestaan, omdat de ontvanger bepaalt hoe de layout wordt in plaats van de afzender.

XMmaiL

DTD

<!ELEMENT message ( messageid, timesent, thread, subject, sender, replyto, recipients, content, attachments?, includedmail? ) >

<!ELEMENT messageid ( #PCDATA ) >

<!ELEMENT timesent ( #PCDATA ) >

<!ELEMENT thread ( threadid, creationtime ) >

<!ELEMENT threadid ( #PCDATA ) >

<!ELEMENT creationtime ( #PCDATA ) >

<!ELEMENT subject ( #PCDATA ) >

<!ELEMENT sender ( address, display? ) >

<!ELEMENT address ( #PCDATA ) >

<!ELEMENT display ( #PCDATA ) >

<!ELEMENT replyto ( address, display? ) >

<!ELEMENT recipients ( recipient+ ) >

<!ELEMENT recipient ( address, display?, role ) >

<!ELEMENT role ( #PCDATA ) >

<!ELEMENT content ( contentplain, contenthtml? ) >

<!ELEMENT contentplain ( #PCDATA ) >

<!ELEMENT contenthtml ( #PCDATA ) >

<!ELEMENT attachments ( attachment+ ) >

<!ELEMENT attachment ( filename, filetype, filedata) >

<!ELEMENT filename ( #PCDATA ) >

<!ELEMENT filetype ( #PCDATA ) >

<!ELEMENT filedata ( #PCDATA ) >

<!ATTLIST filedata encoding CDATA #REQUIRED>

<!ELEMENT includedmail ( message ) >

Verantwoording

messageid

messageid is de hash van een concatenatie van timesent, subject, sender, replyto en content. Omdat elke server minimaal de messageid en timesent van alle verzonden berichten dient te bewaren, kunnen ontvangers hun berichten verifiëren op integriteit en afzender door zelf het bericht nogmaals hashen en deze hash ter controle op te sturen naar de server van de vernomen sender. Daarnaast kan messageid, in combinatie met timesent, voor verschillende doeleinden (bijv. indexeren) worden gebruikt als unieke sleutel binnen een mailapplicatie.

• recipients wordt niet meegenomen in het hash-proces omdat deze ook de BCC's bevat welke de ontvanger niet zal zien. En zo dus ook niet er uit kan halen door de hash te gaan breken.
• attachments wordt niet gehashed omdat deze erg groot kan zijn en het hashproces daardoor onnodig meer tijd zou kosten
• includedmail wordt niet gehashed omdat deze ook onnodig het hashproces langer kan laten duren en in een verleden ook al geverifieerd zijn.

threadid

threadid wordt eenmalig bepaald en kan dus niet veranderd worden voor een bestaande e-mail, wordt bij reply ook weer in zelfde vorm meegestuurd. Dit kan op verschillende manier werken, bijvoorbeeld door een unieke hashwaarde te gebruiken, bijvoorbeeld op basis van een hash van de content gecombineerd met een timestamp en eventueel nonce(s). Of door middel van lokale aliassen binnen de mailbox van de gebruiker, zeker indien een gebruiker de threading gaat aanpassen.

We willen het mogelijk maken dat gebruikers in hun e-mailapplicatie threads naar eigen inzicht kunnen indelen. De vraag hierna kwam naar voren in eerder onderzoek. Hiermee verbeteren we o.a. het threadingmodel dat Google Mail hanteert, omdat men nu wel zelf threading kan aanpassen maar tegelijkertijd deze indeling niet aan anderen zou opdringen. Tevens zou een gebruiker op deze manier zelf een thread kunnen creeëren.

replyto

Dit is een los element in een message (niet binnen de sender), omdat het reply-adres niet per se van de daadwerkelijke verstuurder hoeft te zijn. Het is een verplicht element, omdat een mailprogramma altijd moet 'weten' waar een reply naartoe moet.

contentplain

Een verplicht element. Dit zou de primaire drager zijn voor de boodschap die een e-mail bevat. Indien gebruik wordt gemaakt van contenthtml zou dit een kopie van dat element zijn, omdat het goed mogelijk is dat iemand gebruik maakt van een e-mailclient welke HTML niet ondersteunt. Of als terugval wanneer een HTML opmaak fouten zou bevatten.

includedmail

We hebben de keuze gemaakt voor één includedmail element per e-mail in plaats van meerdere als een soort lijst. Een includedmail element kan namelijk een eerdere email compleet bevatten incluus het includedmail element wat in die voorgaande mail zou zitten. Zo ontstaat een opeenvolgende streng van huidige mail naar eerdere berichten binnen dezelfde thread.

We hebben gekozen voor een includedmail-element om voorgaande mails binnen de conversatie in op te nemen. In de XML-sturctuur ziet dit er uit als een ketting van mails die in elkaar opgenomen zijn, in plaats van een lijst nevengeschikte mails. Dit is om expliciet aan te geven "dit bericht is een reactie op ..." in plaats van een minder expliciet "andere berichten die toevallig ook in deze mailconversatie voorkwamen...".

Voorbeeld

(template)

<message>

<messageid></messageid>

<timesent></timesent>

<thread>

<threadid></threadid>

<creationtime></creationtime>

</thread>

<subject></subject>

<sender>

<address></address>

<display></display>

</sender>

<replyto>

<address></address>

<display></display>

</replyto>

<recipients>

<recipient>

<address></address>

<display></display>

<role></role>

</recipient>

<recipient>

<address></address>

<display></display>

<role></role>

</recipient>

</recipients>

<content></content>

<attachments></attachments>

<includedmail>

<message>

<messageid></messageid>

<timesent></timesent>

<thread>

<threadid></threadid>

<creationtime></creationtime>

</thread>

<subject></subject>

<sender>

<address></address>

<display></display>

</sender>

<replyto>

<address></address>

<display></display>

</replyto>

<recipients>

<recipient>

<address></address>

<display></display>

<role></role>

</recipient>

<recipient>

<address></address>

<display></display>

<role></role>

</recipient>

</recipients>

<content></content>

<attachments></attachments>

<includedmail>

</includedmail>

</message>

</includedmail>

</message>

<message>

<messageid></messageid>

<timesent></timesent>

<thread>

<threadid></threadid>

<creationtime></creationtime>

</thread>

<subject></subject>

<sender>

<address></address>

<display></display>

</sender>

<replyto>

<address></address>

<display></display>

</replyto>

<recipients>

<recipient>

<address></address>

<display></display>

<role></role>

</recipient>

<recipient>

<address></address>

<display></display>

<role></role>

</recipient>

</recipients>

<content></content>

<attachments></attachments>

<includedmail>

</includedmail>

</message>