antispamantispam

Spam will reduce in the future!

Ever seen spam on starship Enterprise?
– "Captain, incoming message."
– "On screen!"
– "New v1agra store in Delta Quadrant!"

                – translated from René Pijlman in nl.internet.misbruik

The story below can also (partly) be found in English at the SpamCop website.

Wat is "spam" of UCE/UBE? Er zijn vele definities voor deze woorden te vinden. Het overeenkomstige woord wat altijd terugkomt is "ongevraagd" en dus ongewenst. Daarbij komt ook nog, voor mij in iedergeval, is dat iedereen die met mij wenst te communiceren, zich dient te houden aan een aantal regels. Alle electronische communicatie-middelen zijn beschreven in zogenaamde RFC‘s. Ik verwacht dat eenieder deze fundamentele bouwstenen respecteert en ook naleeft. Zo gebruik ik een actief filter om berichten te weren van afzenders waarvan bekend is dat zij vinden dat deze regels niet op hun van toepassing zijn. Voor e-mail maak ik gebruik van de database van RFC-Ignorant.

Een probleem is, dat iedereen zich kan voordoen als iedereen met veel communicatie-middelen. Daarom heb ik voor mezelf besloten dat, na het naleven van de bouwstenen, het criterium "gevraagd" het zwaarst weegt. Dit houdt in dat allerlei goedbedoelde automatische berichten, zoals "Out of Office"-meldingen, NDR’s (Non Delivery Reports) en "Challenges" ongevraagd zijn en in aanmerking komen om te worden aangemeld via diverse diensten ter kennisgeving en blokkering.

Deze automatische berichten worden verstuurd zonder onderscheid tussen echte en vervalste berichten. Spam- en virus-berichten komen tegenwoordig altijd van vervalste adressen, zodat het lijkst dat ze verstuurd zijn door een onschuldige derde. Wanneer een automatisch bericht een vervalst bericht ontvangt, wordt aan de niets vermoedende ontvanger het bericht verstuurd. Hierdoor zijn deze berichten ongevraagd en ongewenst, en wordt het ‘spam’ en kan het geblokkeerd worden. Er zijn verschillende typen e-mail, welke hieronder worden beschreven, en allen vormen van automatische berichten zijn.

Probleem: Traditionele auto-responders

Beschrijving: Een bericht wordt verstuurd als antwoord op een ontvangen bericht om de veronderstelde verzender te informeren over je vakantie, ‘veel-gestelde-vragen’ of een andersoort standaard bericht – en regelmatig naar de verkeerde persoon.
Oplossing: Gebruik dit soort oplossingen niet. Informeer je veel gebruikte contacten over je afwezigheid voor je vertrek. Of laat een collega je e-mail lezen en eventueel beantwoorden tijdens je afwezigheid. Publiceer een lijst met VGV (veel-gestelde-vragen) op een website. Als je informatie via e-mail wil geven, een ‘reject’ met meer informatie is makkelijker. Wanneer je sendmail gebruikt, kan je dit aanpassen in de access.db-tabel:
to:oldaddress@example.com 550 Old address no longer valid, please see: http://www.example.com/NewAddressInfo.html

Probleem: Bounces naar vervalste afzender

Beschrijving: Wanneer een mailserver eerst een bericht accepteerd en later besluit dat het bericht niet afgeleverd kan worden, het is verplicht om een bounce e-mail te versturen naar de verzender van het originele bericht. Deze bounces worden vaak naar het verkeerde persoon gestuurd.
Oplossing: Upgrade of her-configureer je mailserver software zodat deze situatie niet kan voorkomen. Configureer de software zodanig om berichten direct bij afleveren te weigeren of accepteer de berichten permanent. Laat de software geen beslissing nemen of het bericht afgeleverd dient te worden, nadat het in eerste instantie het bericht heeft geaccepteerd. Als je het bericht moet accepteren voordat de status bekend is, sla het bericht dan intern op – stuur of bounce het bericht naar buiten de organisatie. Het foutieve bericht kan bijvoorbeeld in een speciale folder worden opgeslagen of gerouteerd worden naar de beheerder.
Vermijd het uitbesteden van het berichten-filteren naar willekeurige derden. Filter uw eigen berichten, vraag niet aan anderen deze taak voor u te doen.
SpamCop heeft voor een aantal populaire mailservers oplossingen staan om deze NDR’s (Non Delivery Reports) te voorkomen:
http://www.spamcop.net/fom-serve/cache/329.html#bounces
Het is belangrijk om een plaag van verkeerd geadresseerde bounces te voorkomen. Veel mensen filteren al alle bounces, omdat ze geen onderscheid kunnen maken tussen verkeerd geadresseerde en echte bounces. Dit leidt tot een verdere afbreuk van het medium e-mail en haar betrouwbaarheid.

Probleem: Challenge/response spam filtering

Beschrijving: Deze "egoïstische" methode van spamfiltering reageert op alle e-mailberichten met een "challange" – een bericht waarop (theoretisch) alleen een natuurlijk persoon kan reageren. Er zijn meerdere problemen met deze methode welke reeds jaren bekend zijn.

  1. Het schaalt niet: Als iedereen deze methode gebruikt, dan ontvangt niemand meer e-mail.
  2. Irritant: Veel ontvangers weigeren te reageren op de "challenge" e-mails, ze weten niet wat het zijn en wat ze doen.
  3. Ineffectief: Door de verwarring over deze berichten, veel van hen worden bevestigd door mensen die ze niet geactiveerd hebben. Hierdoor wordt het originele ongewenste bericht alsnog afgeleverd.
  4. Egoïstisch: Hier ben ik het meest ongerust over. Door het gebruik van een C/R (Challange/Response)-filtering vraag je ontelbare onbetrokkenen om jouw "challenge" te ontvangen, zodat een relatief klein aantal doorkomt bij de bedoelde ontvanger.

Veel partijen hebben een C/R-systeem geïmplementeerd, maar velen hebben het ook weer afgeschaft. Een site die het probleem van C/R-systemen beschrijft: Challenge-Response Anti-Spam Systems Considered Harmful.
Oplossing: Gebruik geen C/R-filtering. Ondanks dat het systeem veel ongewenste berichten tegenhoudt voor de te beschermen persoon, maakt het meer ongewenste e-mail voor anderen.
Aangezien steeds meer beheerders deze "challenges" blokkeren, kan je nooit zeker zijn dat de beoogde ontvanger je bericht ontvangt, zelfs als ze niet verkeerd geadresseerd zijn. Hierdoor zullen deze systemen ook legitieme berichten kwijtraken in een poging ongewenste berichten tegen te houden.

In het algemeen, al deze berichten worden verstuurd naar personen waarvan het e-mailadres is gebruikt zonder toestemming. De ontvangers hebben dus gelijk zal ze deze berichten als ongevraagd beschouwen. In extreme gevallen, domeins zijn bestookt met verkeerd gestuurde e-mails, waardoor het ontvangen van legitieme e-mail onmogelijk is geworden.

Maar…

Vraag: Waarom geen bounces toestaan? Ze worden door RFC822 als verplicht gesteld!
Antwoord: Ondanks dat ze zijn verplicht, is het mogelijk de situatie waarin te voorkomen (zie boven). Ze zijn dus niet echt verplicht, tenzij je jezelf ‘in de hoek hebt gewerkt’.
Vraag: Is het mogelijk om het probeem te verminderen zonder auto-responses compleet te vermijden?
Antwoord: Ja, door de recente pogingen het probleem ’te repareren’, is het mogelijk. Als je auto-reponsders moet blijven gebruiken, dan kan je de nauwkeurigheid verhogen (en het risco om geblokkeerd te worden vermijden). Door deze methodes te gebruiken, je auto-responder zal niet altijd reageren op elke legitieme e-mail. Het reageert op de meeste berichten, en het zal veel minder (maar geen nul) onterechte berichten versturen.
Hiervoor moet je door gebruik van SPF en/of Domain Keys om de authenciteit van het bericht te verifieren. SPF is veel verspreider in gebruik, maar Domain Keys is betrouwbaarder en foutvrij. De meeste verzenders die Domain Keys gebruiken, hebben ook SPF geïmplementeerd (er is geen nadeel om beiden te gebruiken). Samengevat, het controleren op SPF geeft je de meeste voordeel met de minste inspanning.
Vraag: Als ik uitgestelde bounces toestaan, wordt ik dan niet een doelwit voor een woordenboek aanval op geldige adressen?
Antwoord: Ja, als je geen andere maatregelen neemt, zullen spammer makkelijk veel gebruikersnamen kunnen proberen. Er zijn andere, betere manieren om dit probleem te verminderen zoals tarpitting. Het versturen van uitgestelde bounces naar alles en iedereen is geen goede manier om een woordenboek aanval te voorkomen – het doet anderen kwaad en het voorkomt niets.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.