Research and Development 1/^Archief/2009-2010/13/werkplaats/protocol

• Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Ramon van Sparrentak" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Dennis Brentjes" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Frank van der Graaff" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• "Protocol" komt niet voor in de lijst (Logboek, Planning, Projectpagina, Pilot, Fase 1, Fase 2, Groepspagina, Feedback) met mogelijke waarden voor de eigenschap "Type".

Abstract

Implementatie van LINSEP (LINSEP Is No Spam Email Protocol). Een protocol voor het sturen van emails en tegen het sturen van spam. het protocol is alleen voor het versturen van email (vanaf een client of server) naar een Email server. Dit protocol is dus een vervanging voor het oeroude SMTP.

Protocol Outline

Een client (gebruiker) begint met het sturen van een Email naar de Sender (zijn emailserver). De Sender stuurt de Email door naar de Receiver (de ontvangende emailserver). De Receiver kan dan beantwoorden met een Captcha, die de gebruiker zal moeten oplossen voordat de email echt bezorgd is. De gebruiker verstuurd daarvoor de Email opnieuw, inclusief de Captcha oplossing.

Email

Een email bestaat uit een header een body. De body bevat het daadwerkelijke geschreven bericht. De header bestaat uit verschillende onderdelen. Verplichte onderdelen zijn:

• From-, To-,CC- en BCC-addressen
• Digitale handtekeningen
• Datum en tijd
• Message ID

Mogelijke extra onderdeel is bijvoorbeeld:

• Captcha oplossing

Een onderdeel begint met zijn naam en vervolgens de inhoud van het onderdeel zelf.

Captcha

Een captcha wordt teruggestuurd vanaf de Receiver naar de Sender (server) als de Receiver zeker wilt zijn dat het bericht verstuurd is door een mens. Een captcha bestaat ook uit onderdelen:

• From- en To-,CC-,of BCC-addressen (van de Email)
• Message ID (van de Email)
• Het captcha object

Voorbeeld

De client stuurt naar haar server(example.org) de volgende Email:

-Header-
From: alice@example.org
To: bob@foo.bar
Date: 2-10-2010 18:49 UTC
ID: 143494
-Body-
Subject: Hello bob
Body: What's up?

Hoe alice zichzelf authentificeert bij de server laten we open [TODO?]. Haar server voorziet de email van een digitale handtekening dat het inderdaad van (example.org) kwam en alice@example.org ook een correcte gebruiker/emailaddress is. De server stuurt de nieuwe Email naar bobs email server(foo.bar):

-Header-
From: alice@example.org
To: bob@foo.bar
Date: 2-10-2010 18:49 UTC
Signature: example.org [binaire data....]
ID: 143494
-Body-
Subject: Hello bob
Body: What's up?

Bobs emailserver controleert de Email in de volgende stappen

• De datum: emails die ouder zijn dan 2(?) uur worden niet geaccepteerd.
• De handtekening: om er zeker van te zijn dat de email van example.org kwam en dus verstuurd is door de 'eigenaar' van alice@example.org.
• Whitelists en blacklists
  • Staat alice@example.org in bob's whitelist?
  • Staat alice@example.org in bob's blacklist?
  • Staat example.org in bob's whitelist?
  • Staat example.org in bob's blacklist?
  • Staat example.org in de servers whitelist?
  • Staat example.org in de servers blacklist?

In dit voorbeeld staat de email niet in een van de white en blacklists. Dus beantwoord foo.bar met een Captcha:

From: alice@example.org
To: bob@foo.bar
ID: 143494
Captcha: image [binaire data...]

Alices server toont de captcha aan Alice, die de oplossing invult, waarna example.org de email opnieuw verstuurt:

-Header-
From: alice@example.org
To: bob@foo.bar
Date: 2-10-2010 18:49 UTC
ID: 143494
Captcha-result: md5(appel alice@example.org)
-Body-
Subject: Hello bob
Body: What's up?

Bobs server heeft Captcha oplossing en de bijbehorende Message ID,From en To, onthouden en bezorgt de Email in Bobs emailbox. Bob kan er nu zelf voor kiezen of hij alice@example.org of example.org aan zijn whitelist wil toevoegen, waardoor Alice bij het volgende bericht niet opnieuw een Captcha moet oplossen.

Bewijs geen spam

In principe moet voor elke email een Captcha worden opgelost. Captcha's moeten worden opgelost door de verzender die daar de tijd voor neemt

• De captcha kan niet door een ander persoon opgelost worden
  • De captcha kan niet doorgestuurd door zelf een email te ontvangen. Het antwoord zelf wordt namelijk niet doorgestuurd, alleen een bewijs (md5sum) dat de oplosser ook de oplossing heeft
  • Via high traffic sites bezoekers laten oplossen. Dit is echter onwaarschijnlijk/zeer weinig [1]

Als er geen Captcha hoeft te worden opgelost is de zenderaddress op een whitelist.

• Het zenderadress is ook eigendom van de zender.
  • De versturende server is de enige die de correcte handtekening kan zetten behorende bij het domein van de emailaddress
    • Daarvoor moet de handtekening niet gekraakt zijn (afhankelijk van de handtekening die gebruikt wordt)
  • De ontvanger moet de handtekening kunnen controleren
    • Uhm?

Als de zender staat op de whitelist van de gebruiker

• Dan heeft de gebruiker zelf toestemming gegeven, om alle email van deze zender in de inbox te bezorgen

Of de zender staat op de whitelist van de server

• Dan is de server of niet goed ingesteld of heeft een fout gemaakt
  • In beide gevallen is het geen betrouwbare server en voor mensen die geen spam willen niet de server om nog te gebruiken voor email.

De zwakste schakels zijn:

• Captcha's kunnen alleen door mensen worden opgelost
• Digitale handtekeningen worden niet gekraakt
• De digitale handtekening kan correct worden geverifieerd
• Servers / mensen gaan niet ad hoc adressen op whitelists zetten