Mag je info@ adressen spammen? (en een webdevelopervacature)

spam-verboden.pngNaar aanleiding van onze vacature voor een webdeveloper met dreigende taal tegen acquisitie kreeg ik onder meer deze reactie via Twitter:

Een algemene [acquisitiemail] naar info@ is denk ik wel vrijgesteld (art 11.7 2a). (niet van mij hoor)

Die dreigende taal? In onze vacature hebben wij staan:

Acquisitie op basis van deze advertentie wordt niet op prijs gesteld en kan juridische consequenties hebben.

De juridische consequenties zouden dan een tip bij de ACM zijn wegens spammen: het ongevraagd sturen van commerciële berichten is immers verboden (art. 11.7 Telecommunicatiewet). Ook als het maar één mail is die op maat geschreven is. Of wellicht gaan we civiele schadeclaims indienen op diezelfde grond.

Maar dat lid 2a dan? Inderdaad, er staat een uitzondering op het spamverbod in de wet. Bij bedrijven (zowel eenmanszaken als rechtspersonen) is geen toestemming nodig als je een commerciële mail stuurt

indien de verzender bij het overbrengen van de communicatie gebruik maakt van elektronische contactgegevens die door de gebruiker daarvoor zijn bestemd en bekendgemaakt, en deze zijn gebruikt in overeenstemming met de door de gebruiker aan die contactgegevens verbonden doeleinden, of

Oftewel, als je zégt “stuur me hier alsjeblieft een aanbieding” op je website dan is het geen spam als mensen dat doen. Ik heb deze clausule nooit begrepen, volgens mij geef je gewoon tóestemming dan wel vraag je om deze aanbieding dus dan is het niet meer ongevraagd. Maar goed.

Een info@ adres is gewoonlijk voor algemene communicatie een bedrijf, en meestal wordt dat ook wel bekendgemaakt met teksten als “Vragen, interesse, mail ons!”. Mag je daaruit concluderen dat het info@ adres mag worden gespamd?

Dat gaat me toch wat ver. De wet vermeldt dat het adres daarvoor moet zijn bestemd en bekendgemaakt, oftewel voor het soort berichten dat de spammer stuurt. Ik denk dat dat toch echt betekent dat het een specifieke aanduiding moet zijn: “Kent u iemand die deze vacature kan vervullen of kunt u bemiddelen, dan horen we graag van u”. Of “Wie goedkope toner voor onze fax heeft, laat het even weten”. Er moeten immers bepaalde doeleinden bij staan en je moet in overeenstemming daarmee handelen.

Dus nee, het gaat me te snel om te zeggen dat je info@ adressen mag spammen. Je zult echt moeten laten zien dat het adres voor jouw soort berichten is opengesteld, en dat vereist meer dan enkel “info@ is de verzamelbak voor alles”.

Enne oh ja die vacature: Laravel, Symfony, Elastic én juridische zaken, wat wil je nog meer. Reageren kan tot 23 september! (update: schaam over typefout in Laravel en Symfony)

Arnoud

20 reacties

  1. Bleh! PHP… 🙂

    Zelf heb ik een contact@ mailbox in gebruik die ik aan een Google Group heb gekoppeld. Hierop zit net als bij GMail een goede spamfilter en komen alle mails eerst binnen in een moderation box. Als ik daarin een afzender aanmerk als spammer dan kan er vanaf dat adres nooit meer email naar mijn contactadres verstuurd worden. Die andere mails zal ik dan ook niet eens zien verschijnen.

    Wat ik wel toelaat komt dan in de groep waar het mooi wordt gearchiveerd. in mijn normale mailbox ontvang ik alleen maar een digest (samenvatting) dus deze mailboox stoort mij niet en iedereen mag ernaar mailen. Deze nakijken doe ik misschien 1x per dag, waarbij ik voornamelijk de onderwerpen snel lees.

    Want om eerlijk te zijn, ik krijg dagelijks tientallen, zoniet honderden spamberichten binnen en het is zinloos om ze allemaal te gaan aanmelden bij de ACM.

    En serieus… Heb je nooit nagedacht om over te stappen naar Java of ASP.NET? Of misschien zelfs Python? 🙂

    1. Mwah, PHP is goed waar het oorspronkelijk voor bedoeld is: een snelle “hack” om wat server-side functionaliteit in te voegen in HTML-pagina’s. Ja, je kunt er complete frameworks in bouwen (zoals in elke taal), en nee, dat is niet zo handig (want foutgevoelig). Genoeg om een programmeertaal-flamewar te starten? 🙂

      ASP.NET: bind je jezelf daarmee niet vast aan microsoft-software? En hoeveel beter is het dan PHP? (ik ken het niet zo goed). Java: is wel een nette taal. Misschien iets te net: je hebt vrij veel boilerplate-code nodig om iets gedaan te krijgen. Python: ja, leuk! Schaalt redelijk goed van “quick hack” naar grote toepassingen. Ik hoor niet zo veel van web-toepassingen die Python gebruiken; waarom niet?

      1. Tja, met Java bind je jezelf juist weer aan Oracle en met PHP eigenlijk weer aan Linux/Apache/MySQL. Dat is het probleem van iedere programmeertaal.

        Python wordt regelmatig door Google gebruikt en is meer dan een web-ontwikkeltaal. Het is meer een scripting-taal die zelfs door desktop-applicaties soms wordt gebruikt. Zo gebruik ik Poser Pro voor het maken van CGI plaatjes en die gebruikt Python 2.7 voor scripts.

        Ik heb sowieso het gevoel dat de keuze voor PHP vooral komt vanwege WordPress als keuze voor dit blog en dat Arnoud hier zelf ervaring mee heeft. Dan ga je ook niet snel meer voor andere oplossingen kiezen, want als het eenmaal werkt, dan werkt het en moet je er niet meer verder mee knoeien… 😉

        Toch vraag is het mij af of het voldoende blijft om alleen PHP te blijven gebruiken. Misschien zou Arnoud ook andere alternatieven eens moeten overwegen.

        1. “Vastzitten” aan een multiplatform open source implementatie van een taal is toch iets anders dan vastzitten aan een closed source single platform implementatie. Java, Python en PHP zijn alledrie multiplatform; ik denk zelfs dat PHP ook wel buiten Apache gebruikt kan worden, en het kan zeker zonder Linux, en met een andere database dan MySQL. Python en PHP zijn zeker open source; Java volgens mij ook.

          En dan kunnen er natuurlijk nog meerdere implementaties zijn. De kans daarop is natuurlijk groter bij talen waarvan de “kern” van de taal klein en eenvoudig is. Ik verwacht dus niet dat PHP alternatieve implementaties heeft, of ooit zal krijgen. Python heeft wel meerdere implementaties; Java ook (Google/Android: in ieder geval runtime en deel van de standaard libraries; compiler misschien niet). Ik weet niet of er alternatieve implementaties van ASP.NET zijn; ik verwacht het niet.

          1. Maar het ASP.NET framework is ook bedoeld voor multi-platform toepassingen. Het draait immers ook onder Linux en Mac OS X. Er zijn dan wel een paar uitdagingen om op te lossen maar die heb je ook met Java, Python en PHP.

            PHP heeft overigens ook meerdere alternatieve versies. PHP is nog vrij lang populair gebleven nadat PHP5 uitkwam, wegens compatibility-problemen. PHP6 was een mislukt probeersel en kun je maar heel moeilijk terugvinden. PHP7 is de nieuwste versie maar de migratie naat PHP7 gaat ook niet helemaal vlekkeloos.

            Python heeft in principe maar 2 versies, namelijk de 2.7 branch en de 3.x branch. Google en enkele anderen houden vast aan de 2.7 variant.

            Bij ASP.NET zijn de varianten voornamelijk gebaseerd op de .NET versie maar die zijn goed backwards compatible. Een andere verandering is de overstap van WebForms naar MVC, die redelijk snel van MVC1 tot en met MVC5 omhoog ging. Met MVC zijn er wel enkele migratieproblemen geweest maar dat stelt uiteindelijk weinig voor.

            Google/Android gebruikt in principe alleen Java Bytecode om dat weer verder te compileren naar hun eigen formaat. (De Android Runtime, of ART.) Java is de meest bekende compiler die Java bytecode produceert maar niet de enige. Vandaar dat bij Android alternatieven beschikbaar zijn. Maar Google werkt er nu aan om geen Java Bytecode meer nodig te hebben. Samen met Microsoft, Apple en nog een aantal grote bedrijven wordt nu gewerkt aan LLVM, een alternatieve virtuele machine-omgeving waar diverse compilers naartoe kunnen compileren.

            Probleem bij Android is namelijk dat er vele soorten hardware ondersteund moeten worden, en dus vindt de laatste compileer-actie bij Android plaats op het moment dat je een app installeert. Dus de uiteindelijke compilatie gebeurt op je mobieltje. Verder heeft Android alleen maar een standaard intermediair formaat nodig.

  2. Ik ben een prive persoon, en heb een (aantal) eigen domein(en). Met een wildcard email adres, dus inclusief een info@ adres. Ik moet de eerste spammer nog tegen komen die netjes heeft uitgezocht of ik wel of niet een bedrijf ben…

  3. Ik denk dat dat toch echt betekent dat het een specifieke aanduiding moet zijn: “Kent u iemand die deze vacature kan vervullen of kunt u bemiddelen, dan horen we graag van u”. Of “Wie goedkope toner voor onze fax heeft, laat het even weten”. Er moeten immers bepaalde doeleinden bij staan en je moet in overeenstemming daarmee handelen.

    Als u vragen heeft, mail dan naar info@domein.tld Dat lijkt me dan een zeer open mogelijkheid om te vragen of je een dienst of product aan ze kan slijten.

  4. info en andere email adressn is in de digital wereld gelijk aan aan waar je je post naar toestuurt, een postbus, een brief adres of een huis adres.

    Denk dat de geleerde Heren en Damen isn hun onmoelijke wijsheid voorbij gaan aan de essentie van de zaak – electnonic mail en of electronic messagning. – de drager is een digitaal of analoog signal gemaakt voor transport over de betreffende media die gebruikt wornden tussen verzender en ontvanger. tussen de vershcillnde media die als drageer dienen vindt conversie plaats. Door deze transparante conversie kan de verzender of de ontvanger niet vasttellen wat de gebruikt media is de inhoud vna het bericht orf mail blijft zijn inhoud, contect en strekking houden.

    • de basis vna de communictie is het intenrt protocol suite. hier instaat duildelijk gedefnieerd wat een medium en een bericht

    Gebaseerd op voorgaande is het goed mogelijk om hand gescherven brbricht te versturn en de ontvanger dit in mahcinieshcrift leest of voorgelezen krijgt.

    Met dit in het achterhoofd over de technishce defintie en standarisergin die van toepassing isnamelijk dat gebruik wordt voor transport van een medium en het bericht niet veranderd door het gebtruikte transport medium van het bericht of mail (= post in nederlands) kijrg men dat wannner men dit doortrekt ook gebaseerd op de voorgenoemde tehcnishce eisgenschappen, standaarden en definities ook fisiske post en adres hier ondervalt.

    Uitsluitend email is alleen de drager is anders dan bij fysiek mail waardoor de de kosten structuur is anders voor de rest hetzelfde. een beircht versturen naar een adres (electronishc of fysiek) dior de verzender. Dit beircht wordt op een gegeven moet ontvangen Zowel bij een fysiek of digitaal berifcht weet niet wie het gelezen heeft en of het authentiek is of niet gemodificeerd.

    Graag trekt men alles uitlekaar en will alles anders laten lijken het kern van de zaak is hetzelfde en kort samengevat: Spammen naar een adres op een website of in een email vemreld is hetzelfde als post versturen naar en fysiek adres.

    1. Er is een nieuwe meelproducent die z’n bloem 25% goedkoper dan de concurrentie aanbiedt. Deze nieuwe partij stuurt een ongevraagde reclame mail naar alle bakkers in Nederland. Jouw advies aan de bakkers zou dus zijn: blijf maar gewoon teveel betalen voor je bloem, want voor je het weet krijg je ook nog ongevraagd veel goedkopere gist aangeboden?

      1. Gaat dat aanbod ook naar de biologische bakkers terwijl het bedrijf aleen bulkmeel aanbiedt?

        Gaat dat aanbod ook naar de glutenvrije bakkers die hun klanten niet met tarwemeel willen vergiftigen?

        Krijgen bovenstaande bakkers ook nog een wekelijkse herhaling van het aanbod omdat ze nog niet gereageerd hebben?

  5. Met welke intentie publiceren bedrijven mailadressen op hun website?

    …indien de verzender bij het overbrengen van de communicatie gebruik maakt van elektronische contactgegevens die door de gebruiker daarvoor zijn bestemd en bekendgemaakt, en deze zijn gebruikt in overeenstemming met de door de gebruiker aan die contactgegevens verbonden doeleinden.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.