Research and Development 1/^Archief/2009-2010/13/werkplaats/nsSMTP
- 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.
- "NsSMTP" komt niet voor in de lijst (Logboek, Planning, Projectpagina, Pilot, Fase 1, Fase 2, Groepspagina, Feedback) met mogelijke waarden voor de eigenschap "Type".
not so SMTP (working title)
Verbinding maken met de server. Dit gebeurt standaard door de client misschien kleine interface waar de gebruiker het ip van de server moet specificeren en de poort die door de server gebruikt wordt om te “listenen” tot nadere orde lijkt mij 1050 een goede poort het ligt buiten het bereik van 0-1024 die door veel programmas gebruikt worden en als het niet interfereert met andere software in de TK’s lijkt me dit een goed plan om deze even zo te laten.
Je kenbaar maken aan de server dat je wat van hem wil, in smtp was dit het “Helo” or “Ehlo” commando gevolgd door een adress vanwaar je de e-mail verstuurd (hoeft niet hetzelfde te zijn als “from” field).
Helo/ehlo relay.example.com bijvoorbeeld
In ons nog wat simpel ontwerp is dat laatste overbodig omdat we binnen het netwerk blijven en zal dus iets van “Helo” of “Ehlo” voldoende zijn.
“Mail from” is een volgend verplicht onderdeel waar in je zegt waarvan de mail komt. dus dit is waar de mail heen gaat als je deze mail beantwoord. Dit is een van de grotere problemen dat sommige smtp servers dit klakkeloos overnemen en zo dus de spammers anoniem kunnen blijven.
Dit gaan we aanpassen dat dit altijd iets meegeeft dat je kan natrekken bijvoorbeeld ip adress dit heeft wel weer nadelen zodat je alleen maar thuis mail kan versturen. Maar dit is weer op te lossen met bijvoorbeeld een vpn verbinding. Je zou dus ook weer andersom kunnen denken dat spammers naar een ander ip vpn en van op die plek iets sturen. Maar dan moeten ze eerst die verbinding hebben en dus vertrouwd zijn met de personen daar. En zo ja contacten hebben met die mensen.
Volgend probleem hiermee is het dynamisch ip adress waar nu nog veel van de spam mail wordt verstuuurd.
Rcpt to is het commando waarmee je de mensen die de mail moeten ontvangen kunnen worden toegevoegd. Deze worden ook meteen aan de mail header toegevoegd zodat er niet later nog opnieuw mee geschoemeld kan worden wat in het huidige smpt protocol wel kan als je tenminste een “slechte server” weet te vinden.
Data geeft vervolgens aan wat de body van de mail is. En die wordt bijgevoegd bij het pakket dat verzonden wordt met de hier boven vastgestelde header.
Vervolgens als de gebruiker klaar is met de body van de mail te typen genereert de Server een pseudo random (hexadecimaa) getal. Waarmee de HASH code van de mail mee moet overeen komen (inclusief header) zodat er niet meer mee geprutst kan worden nadat deze stap is voltooid. Natuurlijk is dit in 99.9% van de gevallen niet zo en voegt de client random bits bij de mail gestart door een vast bit patroon zodat de ontvanger deze “garbage” er makkelijk af kan halen en dus een schoon mailtje ontvangt. Als dit eindelijk klopt wordt de mailt door de server in behandeling genomen.
| Het is toch van belang dat de ontvanger juist controleert of de zender 2 seconden bezig met t versturen? De server van de zender is namelijk niet te vertrouwen | ||
| Ramon van Sparrentak → Research and Development 1 | Remove this comment when resolved! | |
|
je hebt gelijk, maar hoe bepalen we dan tot hoe ver de mail aangevuld moet worden met garbage? en hoe geven we dat betrouwbaar terug aan de receiver zonder dat de sender met de server kan kloten. want nu kan de sender zo met de server messen dat zijn hash code meteen overeenkomt en dus juist geen extra tijd verspilt met de mail en dus nog steeds even hard kan spammen. |
 |
|
| Dennis Brentjes → Research and Development 1 | Remove this comment when resolved! | |
|
Dit lijkt op het eerste gezicht een goed verhaal. Ook domeinen whitelisten. Ik vraag me af hoeveel gedoe het voor de gebruiker in de praktijk is. Als een zender voor het eerst een mailtje wil sturen naar een ontvanger, wordt eerst bij de ontvanger gecontroleerd of de zender (of het domein van de zender) gewhitelist is. Als dit niet zo is, wordt een bericht teruggestuurd naar de zender dat deze een captcha moet oplossen, en vervolgens het bericht weer op moet sturen. Als de mail dan weer opgestuurd wordt (met opgeloste captcha en digitale handtekening van de zender) wordt het ontvangen door de ontvanger, die dan kan kiezen of hij de zender wil whitelisten, en slaat de handtekening/zender-combinatie op. |
||
| Frank van der Graaff → Research and Development 1 | Remove this comment when resolved! | |
|
Voor de gebruiker valt het wel mee denk ik. Als je een mailtje stuur moet je soms een captcha oplossen soms niet. Als je beetje normaal internet hebt, krijg je dat binnen een halve seconde te zien zodra je op Send drukt. Whitelisten kan ook vrij makkelijk. Bv, als je een reply stuurt op een email, kan de server er vrij zeker van zijn dat het geen spam is en het meteen whitelisten. Met een Spam/Ham knop bij elke email kan server vrij eenvoudig bepalen wat wel en wat niet gewhitelist moet worden. Een gemiddelde gebruiker hoeft de whitelists nooit te zien. Wat me wel een probleem lijkt is de vrij grote hoeveelheden captcha's. Goede captcha's maken is een probleem op zich. En daarbij ook de computation kosten van de server. |
||
| Ramon van Sparrentak → Research and Development 1 | Remove this comment when resolved! | |
|
Is het inderdaad niet makkelijker om of een moeilijk berekening terug te sturen naar de versturende client ik bedoel als er een stuk of 1 miljoen mailtjes terug komen voor verificatie en die allemaal de computer lastig vallen met een complexe berekening gaat die denk ik wel plat. of natuurlijk iets wat wel iets van de gebruiker vraagt maar dan een simpele set van vragen zoals ben je een spam bot j/n. of ben je een man of vrouw. een computer kan deze als het goed is niet parsen en of de gebruiken man of vrouw in vult boeit niet want daarmee bewijst deze al dat het een mens is. of zoiets van "wat is het derde woord van deze zin?" geen idee zoiets in ieder geval |
|
|
| Dennis Brentjes → Research and Development 1 | Remove this comment when resolved! | |
We weten nu waar de mail vandaan komt en kunnen deze persoon op aan spreken als hij daadwerkelijk gespamd heeft. En door deze random gegevens toe te voegen totdat de HASH code (of deel heirvan) klopt met het door de server geleverde (hex) getal duurt het even voordat het mailtje daadwerkelijk verstuurd wordt. Natuurlijk is dit voor dagelijks gebruik geen probleem om even 2 seconden te wachten, maar als je van plan was om 10 miljoen e-mailtjes te versturen. Is dat natuurlijk iets minder prettig.
Om te voorkomen dat automatisch gegenereerde berichten worden verstuurd, zal de server van de ontvanger een Captcha geven aan de zender. Als de zender die voltooid(binnen x minuten) is het bericht verstuurd door een mens.
Omdat het niet handig is bij elke mailtje zo'n Captcha test te moeten voltooien, kunnen ontvangers white lists maken van emailaddressen. Dit is ook nodig voor bijvoorbeeld mailing lists, automatische email voor website registratie e.d.
Om de herkomst van emails te controleren moet elk emailtje een digitale handtekening hebben. Dit kan de zender zelf doen met een persoonlijke handtekening of de email server van de zender met een handtekening van de server. Zo kan de ontvanger controleren dat t echt van de zender kwam, of iniedergeval van de zenders server. Dit voorkomt spoofing van emailadressen die op whitelists staan van gebruikers.
Een gebruiker kan bijvoorbeeld instellen dat alle emails van @gmail.com en @hotmail.com nooit spam zijn, mits de handtekening correct is.
Voor een spammer is het nu praktisch onmogelijk om ongewenste spam te (blijven) versturen. Een spammer kan niet een emailaddress misgebruiken dat op een whitelist staat, omdat het de digitale handtekening niet kan zetten. Een spammers eigen emailaddress kan op de whitelist van een gebruiker komen, als deze zelf aangeeft graag de spam te ontvangen. Om een email te versturen dat niet op de whitelist staat, zal de spammer een captcha test moeten doorstaan. Dat is mogelijk, maar maakt spam sturen een fulltime job van captcha's.
Captcha[1] Digital Signature[2]
|
Als ik het goed begrepen heb is dit ongeveer wat we van plan zijn ik heb nog wat struikelpunten waar we duidelijk nog even over moeten nadenken naar boven gebracht aanvullingen en verbeteringen zijn van harte welkom (voor spelfouten zullen er vast en zeker inzitten) vergeet niet wat commentaar achterlaten. |
|
|
| Dennis Brentjes → Research and Development 1 | Remove this comment when resolved! | |
