Op de gratis SSL certificaten van Let's Encrypt bieden wij geen support. Indien wij toch een support ticket moeten behandelen inzake Let's Encrypt, dan rekenen wij daarvoor tech kosten. Deze kosten zijn tijdens kantooruren 30.00 Euro en buiten kantooruren 75.00 Euro (per domein / LE certificaat). Hou hier rekening mee! Uiteraard worden deze kosten niet in rekening gebracht wanneer het daadwerkelijk een server probleem betreft, in alle andere gevallen worden deze kosten wel doorberekend. Op betaalde SSL certificaten van derden leveren wij helemaal geen support.

De reden hiervoor is dat er steeds vaker problemen optreden met deze gratis SSL certificaten en wij geen directe support hebben bij de organisatie bij Let's Encrypt. De enige vorm van support aldaar is via een forum en dat laat (veel) te wensen over. Dus als u problemen heeft met een gratis Let's Encrypt SSL certificaat en u wenst dit te blijven gebruiken, dan zal u zelf op het forum van Let's Encrypt hier melding van moeten maken. Pas daarbij wel op dat u geen (directe) gegevens van uw hostingaccount of server plaatst!

Wij krijgen met regelmaat klachten dat de gratis SSL certificaten van Let's Encrypt problemen opleveren. Niet alleen tijdens het aanmaken, maar ook tijdens het vernieuwen van bestaande Let's Encrypt SSL certificaten. De Let's Encrypt SSL certificaten hebben een korte "levensduur" en worden, normaliter, tussen de 30 en 45 dagen automatisch vernieuwd. Wanneer er een probleem optreed (om welke reden dan ook), dan wordt het certificaat niet vernieuwd of in ieder geval niet correct. Dit kan weer talloze problemen opleveren inzake de website zelf (onbeveiligd), FTP of zelfs emailverkeer hinderen.

Het is niet verwonderlijk dat wij altijd een betaald SSL certificaat adviseren om dergelijke problemen te voorkomen. Tegenwoordig bieden wij ook SSL certificaten abonnementen aan waarbij een SSL certificaat automatisch door ons vernieuwd worden na 1 jaar. Op die manier heeft u het minst hinder van verschillende mogelijke problemen. Voor meer informatie over Let's Encrypt SSL certificaten, betaalde SSL certificaten en SSL certificaten in het algemeen, kijk hier.

Resumé; vanwege de huidige (opstapelende) problemen rondom de Let's Encrypt SSL certificaten en het feit dat wij geen directe support bij Let's Encrypt hebben, heeft ons er toe doen besluiten om hierop dan ook geen support te (meer) te leveren. Dus als u problemen heeft met een dergelijke Let's Encrypt SSL certificaat, dan zal u op het forum van Let's Encrypt het problemen moeten melden of een betaald SSL certificaat afnemen. Het spreekt daarnaast voor zich dat wij alleen support kunnen leveren op SSL certificaten die bij ons zijn afgenomen.

Betaalde SSL certificaten (3rd party)

Inzake support op SSL certificaten die elders zijn aangeschaft, dus niet via ons; hier geldt beperkte support op. Wij zullen ons best doen om te helpen, maar hier kunnen geen garanties aan verbonden worden. Indien wij dit voor u moeten controleren, dan is het aannemelijk dat er tech kosten hiervoor in rekening gebracht worden. Controleer altijd of het door (elders) aangeschafte SSL certificaat nog steeds geldig is en voldoet aan de nieuwste eisen die worden gesteld. Eventueel kunt u proberen om een "re-issue" aan te vragen voor het SSL certificaat bij de organisatie c.q. parrtij waar u het SSL certificaat heeft aangeschaft.

Uiteraard kan u ook altijd bij ons gewoon een professioneel SSL certificaat bestellen. Wij hanteren zeer lage tarieven en u kan zelfs het SSL certificaat door ons laten installeren tegen een minimale meerprijs. Dan heeft u ook alles op één adres en daarbij ook maar één aanspreekpunt inzake mogelijke problemen.

Geen support, wel een aantal mogelijkheden om toch Let's Encrypt te activeren

Wanneer Let's Encrypt problemen vertoond, wat dus steeds vaker gebeurt, dan kan u proberen een Wildcard LE certificaat uit te geven. Het is niet gezegd dat dat wél werkt, maar dit is een andere controle waarbij er een TXT DNS-record aangemaakt wordt voor controle en dus op een andere manier benaderd wordt door Let's Encrypt. Zie hieronder een screenshot bij een Plesk server. Mocht dit ook niet baten, dan zal u op een andere dag moeten proberen (soms 2 á 3 dagen wachten wil ook soms helpen) of een betaald SSL certificaat af te nemen.

Ook bij DirectAdmin heeft u de mogelijkheid om een Wildcard te installeren. Zie hieronder:

Mocht dit eveneens niet werken, dan resteren er twee mogelijkheden; u wacht 2 á 3 dagen of u besteld een betaald SSL certificaat.

LET OP!!! Extra mededeling inzake support ticket inzake Let's Encrypt SSL certificaten !!!

Let op!!! Aangezien er regelmatig toch support tickets worden aangemaakt met betrekking tot de gratis Let's Encrypt (LE) SSL-certificaten, zullen wij vanaf nu standaard kosten in rekening brengen wanneer hiervoor een supportticket wordt ingediend. De kosten bedragen €40,00 tijdens kantooruren en €90,00 buiten kantooruren/weekend (per domein/LE-certificaat). Deze kosten worden uiteraard niet in rekening gebracht als het daadwerkelijk om een serverprobleem gaat; in alle andere gevallen worden deze kosten wel doorberekend.

Daarnaast is dit nog steeds géén garantie dat het onze technici wel lukt om een LE certificaat aan te vragen, immers zijn en blijven wij dus afhankelijk van de uitgifte van LE certificaten. De kosten hiervoor worden dan wel in rekening gebracht. Voor betaalde SSL-certificaten van derden, dus niet via ons aangeschaft, bieden wij helemaal géén support. U zal voor betaalde SSL certificaten via een andere partij aldaar support moeten aanvragen.

Probeer de hierboven eerdere vermelde methoden of wacht enkele dagen (1 tot 3 dagen). En wilt u helemaal geen problemen met LE certificaten iedere 30 á 45 dagen? Neem dan een betaald SSL certificaat voor slechts 14.95 Euro. Dan heeft u een jaar lang geen zorgen en/of omkijken naar een gratis (en vaak problematisch) SSL certificaat!

Tags: LE certificaat, Let's Encrypt, SSL certificaat, problemen LE, Lets Encrypt foutmelding, LE foutmelding, LE firewall melding, Authorization for the domain failed, Could not issue a Let's Encrypt SSL/TLS certificate, Timeout during connect (likely firewall problem), Let's Encrypt SSL certificaat

Vooropgesteld; gezien de vele (en herhaaldelijke) problemen met Let's Encrypt SSL certificaten en slechte (forum) support, leveren wij géén support op de gratis Let's Encrypt SSL certificaten. Zie ook hier.

Er kunnen veel verschillende problemen optreden bij Let's Encrypt SSL certificaten, zo kan u tegen een limiet aanlopen (als u te vaak een gratis LE certificaat aanvraagt) en hier is niks aan te doen, dan te wachten (dit wordt dagelijks gereset bij Let's Encrypt). Let's Encrypt heeft inmiddels het aantal pogingen drastisch verminderd naar drie (3) keer per dag. Na drie keer proberen een LE certificaat te vernieuwen, dan zal u een melding krijgen dat het limiet inzake het aantal pogingen bereikt is en dan moet u minimaal 24 uur (1 dag) wachten voordat u het week kan proberen. Hier kunnen wij niks aan doen/veranderen!

Daarnaast kregen wij in het verleden vaak tickets inzake dat het A- of AAAA-record niet zou kloppen. Vaak is dit probleem te wijten aan een domeinnaam alias die ook gekoppeld staat aan het hoofddomein. Vaak is men vergeten de extra domeinnaam c.q. domeinnaam alias ook te laten verwijzen naar de server. Controleer dus altijd goed de foutmelding. Vaak krijgt men ook een link in de vorm van "https://acme-v02.api.letsencrypt.org/acme/authz-v3/XXXXXX" (waar "XXXXXX" staat voor een cijferreeks). Als men die link dan opent, dan zal u een compleet inzicht krijgen waar de foutmelding betrekking op heeft. Vaak dus op een alias die ooit een keer toegevoegd is door u, maar niet eens actief / geregistreerd is. Verwijder dan de alias of zorg ervoor dat die actief/geregistreerd wordt.

Is dat het geval, dan kun ervoor kiezen om de alias (voorlopig) niet te beveiligen met een Let's Encrypt SSL certificaat, de alias correct laten verwijzen naar de server of gewoonweg de alias te verwijderen. Indien de problemen aanhouden, dan dient men support aan te vragen via het forum van Let's Encrypt hier. Let's Encrypt biedt zelf geen directe support, derhalve bieden wij dit ook dan ook niet aangezien wij ook aan dit forum zijn overgeleverd en support aldaar is behoorlijk beperkt en langzaam.

Dit is dan ook de belangrijkste reden dat wij dus géén support leveren op deze gratis Let's Encrypt SSL certificaten, wat hier ook staat vermeld. Hetzelfde geldt ook voor SSL certificaten die elders, dus niet via ons, zijn aangeschaft/besteld. Wanneer u problemen heeft met een dergelijk (extern) aangeschaft SSL certificaat, dan zal u bij die partij support moeten aanvragen. Wij hebben geen inzicht in SSL certificaten van derden c.q. andere partijen.

Ook krijgen wij regelmatig een melding dat onze firewall Let's Encrypt blokkeert. Dit is NIET het geval! Wij blokkeren helemaal geen diensten of IP-adressen van Let's Encrypt. Dit hebben wij nog nooit gedaan en zullen dit ook nooit doen. Sowieso zijn de IP-ranges van Let's Encrypt niet openbaar en daarnaast gaan wij echt onze klanten niet "pesten" om dit soort zaken te blokkeren.

Op dit moment (2024) geeft Let's Encrypt per dag 2 tot 3 miljoen SSL certificaten uit! Dus dan is het zeer aannemelijk dat er ook meer problemen optreden met een dergelijke gratis dienst. Doordat er steeds meer Let's Encrypt SSL certificaten worden uitgegeven, nemen de problemen dus ook toe. In de afgelopen 5 jaar zien wij een toenname van rond de 60% bij alle Let's Encrypt SSL certificaten. Ook komen deze problemen herhaaldelijk terug omdat de Let's Encrypt SSL certificaten vaak (automatisch) vernieuwd worden tussen de 30 en 45 dagen.

Op een gegeven moment waren 90% van de support tickets op Helpburo gerelateerd aan Let's Encrypt SSL certificaten problemen, waardoor technici amper tijd hadden om "serieuze" problemen op te lossen. Dit alles bij elkaar heeft ons er toe doen besluiten om dus géén support meer te leveren op Let's Encrypt SSL certificaten. Wij willen een goede dienstverlening leveren aan al onze klanten, daarbij kunnen wij ons niet blijven focussen op één bepaald (nota bene gratis) product, waarbij géén directe support ingangen zijn voor ons.

Geen support, wel een aantal mogelijkheden om toch Let's Encrypt te activeren

Wanneer Let's Encrypt problemen vertoond, wat dus steeds vaker gebeurt, dan kan u proberen een Wildcard LE certificaat uit te geven. Het is niet gezegd dat dat wél werkt, maar dit is een andere controle waarbij er een TXT DNS-record aangemaakt wordt voor controle en dus op een andere manier benaderd wordt door Let's Encrypt. Zie hieronder een screenshot bij een Plesk server. Mocht dit ook niet baten, dan zal u op een andere dag moeten proberen (soms 2 á 3 dagen wachten wil ook soms helpen) of een betaald SSL certificaat af te nemen.

Ook bij DirectAdmin heeft u de mogelijkheid om een Wildcard te installeren. Zie hieronder:

Mocht dit eveneens niet werken, dan resteren er twee mogelijkheden; u wacht 2 á 3 dagen of u besteld een betaald SSL certificaat.



LET OP!!! Extra mededeling inzake support ticket inzake Let's Encrypt SSL certificaten !!!

Let op!!! Aangezien er regelmatig toch support tickets worden aangemaakt met betrekking tot de gratis Let's Encrypt (LE) SSL-certificaten, zullen wij vanaf nu standaard kosten in rekening brengen wanneer hiervoor een supportticket wordt ingediend. De kosten bedragen €40,00 tijdens kantooruren en €90,00 buiten kantooruren/weekend (per domein/LE-certificaat). Deze kosten worden uiteraard niet in rekening gebracht als het daadwerkelijk om een serverprobleem gaat; in alle andere gevallen worden deze kosten wel doorberekend.

Daarnaast is dit nog steeds géén garantie dat het onze technici wel lukt om een LE certificaat aan te vragen, immers zijn en blijven wij dus afhankelijk van de uitgifte van LE certificaten. De kosten hiervoor worden dan wel in rekening gebracht. Voor betaalde SSL-certificaten van derden, dus niet via ons aangeschaft, bieden wij helemaal géén support. U zal voor betaalde SSL certificaten via een andere partij aldaar support moeten aanvragen.

Probeer de hierboven eerdere vermelde methoden of wacht enkele dagen (1 tot 3 dagen). En wilt u helemaal geen problemen met LE certificaten iedere 30 á 45 dagen? Neem dan een betaald SSL certificaat voor slechts 14.95 Euro. Dan heeft u een jaar lang geen zorgen en/of omkijken naar een gratis (en vaak problematisch) SSL certificaat!

Tags: LE certificaat, Let's Encrypt, SSL certificaat, problemen LE, Lets Encrypt foutmelding, LE foutmelding, LE firewall melding, Authorization for the domain failed, Could not issue a Let's Encrypt SSL/TLS certificate, Timeout during connect (likely firewall problem), Let's Encrypt SSL certificaat

Aangezien er nog een aantal Plesk reseller nodes nog op een zeer oud besturingssysteem draaide (CentOS 6.x) zijn deze automatisch gemigreerd naar een nieuwere omgeving. Indien uw (oude) Plesk reseller pakket op één van de onderstaande reseller nodes stond, dan is deze inmiddels gemigreerd naar een nieuwe reseller node. De grootste voordeel is dat u o.a. van nieuwere PHP-versies gebruik kunt maken nu (o.a. PHP 8.x).

Verderop deze pagina ziet u welke (oude) Plesk reseller nodes inmiddels zijn gemigreerd naar een nieuwe omgeving. Wij willen u adviseren om de onderstaande informatie toch goed door te lezen. Op die manier bent u volledig op de hoogte van wat er wel en niet is gemigreerd. Door verschillende server configuraties (besturingssysteem, Plesk versie e.d.) kan niet alles gemigreerd worden. Dus lees dit aandachtig door!

Deze automatische migratie betekend niet dat u van alle nieuwe functies kunt gebruik maken die vandaag de dag worden geleverd met de reseller pakketten. U blijft na deze migratie uw "oude" reseller pakket behouden, zoals deze destijds besteld is. Indien u wenst gebruik te maken van de functionaliteiten van de nieuwe reseller pakketten, dan zal u een nieuw reseller pakket hiervoor moeten bestellen. Eventueel kunnen wij uw huidige reseller pakket handmatig migreren naar deze (allernieuwste) reseller node. Normaliter zitten hier dan wel tech kosten aan verbonden.

Zoals hierboven aangegven kan u dus gebruik maken van nieuwere PHP-versies, waaronder dus ook PHP 8.x. Helaas heeft deze migratie ook een aantal keerzijden, namelijk;

• Apache PHP (mod_php) wordt niet meer ondersteund
  • Het uitvoeren van PHP via Apache PHP is onveilig en langzaam
  • U kan gewoon een andere PHP runtime kiezen, zoals PHP-FPM of FastCGI
  • Wij hebben al talloze keren aangegeven dat mod_php end-of-life (EOL) is

• Website functioneert niet meer of geeft een foutmelding
  • Raadpleeg de log-bestanden van uw website
  • Probeer een andere PHP-versie (lager of hoger)
  • Update uw (Wordpress) website en/of PHP programma's
  • Controleer of u niet dubbele index bestanden heeft staan

• Oude PHP-versies worden voorlopig nog ondersteund
  • Alle PHP 5.x versies blijven momenteel ondersteund worden op de server
  • In de toekomst kan dit uiteraard wel veranderen, daar deze versies EOL zijn

• RoundCube adressenlijst/-bestanden zijn niet gemigreerd
  • Dit was niet mogelijk om mee te migreren van de oude server i.v.m. configuratie verschillen
  • Eventueel kan dit handmatig gedumpt en gemigreerd worden door onze technici
    • Hier zitten wel tech kosten aan verbonden (éénmalig 50.00 Euro)
    • Deze kosten zijn noodzakelijk gezien de uitgebreide handelingen

• Installatron backups en/of instellingen zijn niet gemigreerd
  • Bij server migraties worden Installatron backups nooit gemigreerd
  • Dit komt door onderlinge server verschillen, waardoor dit niet mogelijk is
  • Ook handmatig dumpen en restoren is niet mogelijk

• In Plesk gemaakte back-ups zijn niet gemigreerd
  • Bij server migraties worden Plesk back-ups nooit gemigreerd
  • Dit komt door de onderlinge verschillen van OS en Plesk systeem
  • Ook handmatig dumpen en restoren is niet mogelijk
    • Tip: maak na de migratie z.s.m. een nieuwe Plesk back-up
      

Welke Plesk reseller nodes zijn er inmiddels gemigreerd?

Hier een overzicht van de (oude) Plesk reseller nodes die volledig uitgemigreerd zijn:

• ns1.securenameserver5.net
  • Gemigreerd naar ns1.securenameserver1.net
  • Gemigreerd op 17 november 2022

• ns1.securenameserver12.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 18 november 2022

• ns1.securenameserver14.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 17 november 2022

• ns1.securenameserver15.net
  • Gemigreerd naar ns1.securenameserver1.net
  • Gemigreerd op 16 november 2022

• ns1.securenameserver16.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 17 november 2022

De hierboven vermelde oude Plesk reseller nodes, zijn allemaal gemigreerd naar ns1.securenameserver1.net. Dus vanaf nu kan u deze ook gebruiken als zijnde nameservers voor eventuele domeinnaamregistries en/of verhuizingen. Voor de goede orde, u nieuwe nameservers zijn dus als volgt:

• ns1.securenameserver1.net
• ns2.securenameserver1.net

De oude nameservers blijven sowieso (maximaal) 1 jaar actief; dan heeft u voldoende tijd om de nameservers aan te passen. Hetzelfde geldt als u de hostname gebruikt voor de inkomende en uitgaande mailserver. Onderaan deze pagina vindt u de (nieuwe) aanbevolen email instellingen terug voor deze nieuwe omgeving.

Om in te loggen op uw Plesk reseller omgeving, kan u gebruik maken van de volgende link: https://ns1.securenameserver1.net:8443
Uiteraard is ook webmail weer actief op deze Plesk reseller omgeving; deze kan u openen via: https://webmail.securenameserver1.net

De aanbevolen emailinstellingen voor deze reseller node ziet u hieronder terug.

Let op!
Vroeger werd vooral mail.domeinnaam.nl gebruikt. Dit is niet meer van toepassing vandaag de dag. Met dient dus de opgegeven servernaam (zie hieronder) te gebruiken! Deze is namelijk beveiligd met een professioneel SSL certificaat die zorgt voor een beveiligde verbinding tussen uw email programma en de mailserver.

Inkomende email IMAP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 993
Versleuteling: SSL/TLS
Optioneel: hoofdmap instellen op "Inbox" (zonder aanhalingstekens) voor synchronisatie

Inkomende email POP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 995
Versleuteling: SSL/TLS

Uitgaande email SMTP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 587
Versleuteling: STARTTLS

Voorheen werd voor de uitgaande mailserver poort 465 (met SSL) gebruikt. Aangezien deze poort behoorlijk verouderd begint te worden, is vandaag de dag het advies om poort 587 (met STARTTLS) te gebruiken. Zie voor uitgebreidere uitleg hier en hier. Dus wanneer u in de gelegenheid bent, dan adviseren wij u niet meer poort 465 (met SSL) te gebruiken, maar poort 587 (met STARTTLS) voor de uitgaande mailserver. Op die manier zal u ook in de toekomst geen problemen ondervinden met het versturen van email.

In (bijvoorbeeld) Outlook kan u deze instellingen gemakkelijk controleren door te klikken op "Bestand", vervolgens (in het nieuwe scherm) selecteert u het emailaccount waarmee u "problemen" ondervindt. Wanneer u hier het juiste emailaccount heeft geselecteerd, dan klikt u op het icoon met "Accountinstellingen" en aldaar te klikken op "Serverinstellingen". Controleer hier zowel de "Inkomende e-mail"- alsook de "Uitgaande e-mail"-instellingen. Vaak wordt door Outlook automatisch mail.domeinnaam.nl gevonden/gebruikt, dit is echter incorrect!

Wanneer u email problemen ondervindt, controleer dan of uw SPF-record goed staat. Deze moet vergelijkbaar zijn met:

• v=spf1 mx a ip4:83.172.188.51 ip4:83.172.138.9 a:mail.DOMEINNAAM.TLD a:ns1.securenameserver1.net include:relay.mailchannels.net ~all

Met name het laatste gedeelte is zeer belangrijk! Wij gebruiken op alle (nieuwere) reseller nodes een uitgaand mailfilter. Hiermee voorkomen wij dat server op de zwarte lijst komen te staan, wanneer iemand verzuimd om een contactformulier correct te beveiligen of gewoonweg zijn/haar emailadres gehackt is en spam verstuurd. Door dit uitgaande mailfilter voorkomen wij dus dat de mailserver op de zwarte lijst komt en dat niemand meer emails kan versturen. Dus het is zaak om dit de te controleren. Indien u email extern laat lopen lopen, bijvoorbeeld via Gmail of Microsoft, dan is deze aanpassing natuurlijk niet nodig.

De oude nameservers blijven dus maximaal nog 1 jaar actief (tot medio 11.2023). Daarna verlopen de oude nameservers en kan u deze niet meer gebruiken. Hou hier rekening mee!
Indien u vragen en/of opmerkingen heeft inzake de migratie van uw reseller pakket en u heeft het bovenstaande goede gelezen, dan kan u hiervoor een support ticket openen.

Spamprotector biedt een uiterst kostenefficiënte oplossing voor spamfiltering, speciaal ontwikkeld voor onze hostingklanten. Voor resellers en klanten met een eigen server (VPS/DPS) die in bulk inkopen, bieden we bovendien extra scherpe prijsstellingen.

Beperkte ondersteuning vanwege lage prijsstelling

Vanwege de bijzonder scherpe tarieven van Spamprotector, kunnen wij slechts beperkte ondersteuning bieden. Mocht er toch behoefte zijn aan technische ondersteuning, bijvoorbeeld voor diepgaande onderzoeken of uitgebreide analyses, dan kunnen hier technische kosten voor worden berekend. Dit geldt met name voor herhaalde verzoeken of terugkerende problemen.

Gezien het tarief van €16,00 (of zelfs lager bij bulk) per account, is het voor ons helaas niet mogelijk om gratis support te leveren. Vergeet niet dat dit een dienst is die 24/7/365 werkt, dus als je dit terug rekend naar per dag is dit natuurlijk sowieso al een absurd laag bedrag. Daarnaast Spamprotector functioneert in de meeste gevallen zonder problemen, en het merendeel van onze klanten ervaart dan ook een storingsvrije werking. Slechts een klein aantal gebruikers ondervindt aanhoudende problemen, en voor deze gevallen zullen we voortaan technische kosten in rekening brengen wanneer er ondersteuning wordt gevraagd. Buiten kantoortijden geldt een toeslag inzake tech kosten.

Belangrijk om te weten: als u niet akkoord gaat met ons beleid omtrent supportkosten, staat het u uiteraard vrij om Spamprotector op te zeggen en op zoek te gaan naar een alternatieve, betaalbare anti-spamoplossing. Echter, met betrekking tot prijs en functionaliteit zijn er nauwelijks vergelijkbare alternatieven beschikbaar.

We rekenen niet direct technische kosten voor éénmalige vragen, maar als er sprake is van herhaalde supportverzoeken met betrekking tot Spamprotector, dan worden er wel kosten in rekening gebracht. De exacte hoogte van deze kosten hangt af van het type klant dat u bent. Zo zullen hostingklanten met één Spamprotector-account mogelijk minder betalen dan resellers of klanten met een eigen server (VPS/DPS) en meerdere accounts, vanwege de hogere kortingen die we bieden bij bulkverkoop. We raden u aan hier rekening mee te houden.

Om de mogelijke tech en/of onderzoekskosten beperkt te houden dient u altijd zoveel mogelijk informatie aan te leveren, zoals screenshots, headers en duidelijke foutmelding in tekst. Hierdoor kan een eventueel probleem sneller opgelost worden en scheelt dit mogelijk kosten, indien van toepassing.

Geen ondersteuning Spamprotector bij externe diensten

Daarnaast bieden wij geen ondersteuning meer voor Spamprotector in combinatie met externe diensten, zoals Office365, Exchange-servers, domeinnamen of hostingaccounts die niet door ons worden beheerd. Dit soort configuraties zijn complex en vereisen vaak langdurige en intensieve onderzoeken. Dit past niet binnen de prijsstructuur van Spamprotector. Verzoeken om ondersteuning voor Spamprotector in combinatie met externe diensten zullen daarom niet worden behandeld.

Indien u toch wenst dat wij een onderzoek uitvoeren naar Spamprotector-configuraties die via een externe dienst verlopen, dan zullen wij hiervoor onderzoeks- en technische kosten in rekening brengen. Voor dit soort gevallen hanteren wij een standaardtarief van €75,00 per uur tijdens kantooruren. Buiten kantooruren geldt een hoger tarief. Houd er rekening mee dat onze technici volledige toegang moeten hebben tot de externe diensten om effectief te kunnen troubleshooten. Indien deze toegang niet beschikbaar is, kan dit resulteren in aanvullende technische kosten omdat dit moeilijker en (veel) meer tijd kost om te troubleshooten.

Tags: spamprotector, anti-spam, virus filtering, spam filtering, spamprotector bulk, spamprotector support, spamprotector office365, office 365, microsoft office 365

Aangezien er steeds meer verschillende applicaties op de markt komen en door klanten, al dan niet, zelf geinstalleerd (via SSH, DirectAdmin, Plesk, etc.) is het voor ons onmogelijk om hierop volledige support te leveren. Waar wij kunnen leveren wij support, maar dit is natuurlijk zeer beperkt. Onze expertise is server beheer en hostingomgevingen en dus niet support op applicaties via derden.

Zaken waar wij geen of (echt) zeer beperkt support op leveren zijn:

• Magento
  • Magento vereist een bepaalde specialisatie; het is niet voor niets dat Magento specialisten vrij kostbaar zijn, dus daarom bieden wij hier géén support op
  • Bij eventuele problemen inzake uw Magento installatie is het derhalve raadzaam om een specialist in te huren
• Prestashop
  • Wij kunnen controleren op eventuele problemen tegen betaling, maar support hierop is, in het algemeen, zeer beperkt
  • Mocht u support wensen hierop (tegen betaling), dan hebben wij wel toegang tot uw Prestashop (interface) nodig
• Laravel
  • Met Laravel kun je zeer mooie en verschillende PHP applicaties en frameworks bouwen, maar aangezien dit allemaal custom werk is, kunnen wij hier dus geen support op leveren
  • Er zijn diverse communities waar zaken geraadpleegd kunnen worden en vragen gesteld kunnen worden en zelfs problemen voorgelegd kunnen worden
• GitLab
  • Het is voor ons onbegonnen werk om op dergelijke (custom) applicaties support te leveren; er zijn meer dan 31 miljoen GitLab (en GitHub) gebruikers en bijna net zoveel applicaties
  • Derhalve is het verstandiger om zelf contact te zoeken met de beheerder van desebetreffende GitLab/GitHub applicatie of de desbetreffende community te raadplegen
• Custom PHP applicaties
  • Op zelfgeschreven PHP applicaties leveren wij geen support, als u deze zelf heeft geschreven, dan zal u dit zelf moeten oplossen.
  • Indien een derde partij een dergelijke PHP applicatie heeft gemaakt voor u, dan zal u bij hun moeten aankloppen
• Overige custom scripts
  • Idem aan het verhaal inzake "Custom PHP applicaties"

In zijn algemeenheid; wij leveren puur en alleen support op de door ons aangeleverde producten en diensten, niet wat u of uw klanten erop installeren. En wanneer wij ergens op support op leveren, al dan niet tegen betaling, dan zal dit beperken tot het troubleshooten van een probleem (voor zover mogelijk). Onze core business is het leveren van servers en hosting tegen schappelijke prijzen en op deze producten/diensten leveren wij natuurlijk support. In een heel ver verleden hadden onze technici wel verstand van zaken inzake standaard PHP en dergelijke, maar in de afgelopen jaren is dit zo explosief gestegen, dat het daarom voor ons onmogelijk is om op de hierboven genoemde zaken gewoonweg support te leveren.

Daarnaast moet u ook rekening houden met het feit dat wij ondertussen meer dan 1100 servers actief hebben staan, met meer dan 72.000 hostingaccounts met nog meer domeinnamen en SSL certificaten. Deze moeten allemaal beheerd (en onderhouden) worden en eventuele calamiteiten direct worden aangepakt; denk hierbij aan het restoren en of repareren van (gecrashte) databases, problemen inzake hostingaccounts, problemen inzake emailaccounts, etc. Ook zijn onze technici bijna iedere week bezig met 2 á 3 server migraties. Dus wij hebben simpelweg ook niet de tijd om ook nog eens volledige of gedeeltelijke support te leveren op randzaken die niet direct met onze dienstverlening te maken hebben.

Het laatste is ook terug te zien bij bijvoorbeeld Plesk en DirectAdmin; deze boden voorheen altijd support op problemen rondom geinstalleerde applicaties, maar ook zij zijn daarmee gestopt en bieden alleen support op de door hun (direct) geleverde producten. Dit om exact dezelfde reden; er zijn gewoon te verschillende applicaties wereldwijd om hierop allemaal support op te leveren. Zij adviseren altijd om forums, communities of dergelijke te raadplegen of een expert op dat gebied in te huren. Dat is wat wij dus ook doen en dus adviseren.

De enige (directe) uitzondering hierop is Wordpress, daar hierop het meerendeel van alle websites wereldwijd op gebasseerd zijn. Maar ook hierop is support beperkt, daar je talloze thema's en nog een groter aantal plugins hebt. En een "grote" Wordpress website gebruikt al gauw tussen de 10 en 30 plugins. Meestal zijn problemen inzake Wordpress websites te wijten aan een plugin die niet meer onderhouden wordt of een conflict oplevert met een andere plugin. Voor de meeste problemen inzake Wordpress staan op Helpburo verschillende kennisbank artikelen aangemaakt die geraadpleegd kunnen worden. Kom je er nog niet aan uit, dan is het wellicht verstandig om diegene te raadplegen die de Wordpress website heeft gemaakt. Indien u dit zelf bent, dan is het raadzaam om de log-bestanden van uw website na te lopen, meestal kun je dan al de oorzaak vinden. Vervolgens diegene raadplegen die de problematische plugin heeft gemaakt. En mocht dat allemaal niet baten, dan kan u altijd een support ticket aanmaken. Wij kunnen dan kijken voor u en (indien mogelijk) dit oplossen voor (al dan niet tegen betaling).

Uiteraard kan u, ondanks het bovenstaande verhaal te hebben gelezen, een support ticket aanmaken inzake een bepaald probleem. Maar hou er wel rekening mee, dat wij niet genoodzaakt zijn om dit te kunnen oplossen. En daarnaast is het ook afhankelijk van de actuele drukte bij ons en onze technici.

Tags: support op applicaties, support op wordpress, custom php, custom scripts, gitlab, github, git, laravel, prestashop, magento, custom scripting, wordpress plugins, gi

Normaliter plaatsen wij geen individuele bestanden terug. De enige uitzondering hierop is wanneer er een volledige server crash plaats vindt. In dat geval wordt er een volledige kopie van de server teruggeplaatst.

U kan altijd zelf back-up's maken via de Plesk/DirectAdmin interface. U kan dan zelf een back-up terug plaatsen. Daarnaast bieden wij ook nog Backupmaster aan. Indien u hiervan gebruik maakt, dan kunnen wij eventueel voor u een back-up terug plaatsen.

Indien u zelf géén back-up's heeft (via Plesk/DirectAdmin) en/of u geen Backupmaster heeft en u per se wenst dat er bepaalde cruciale bestanden worden teruggeplaatst, dan kan u een support ticket openen. Dan overleggen wij wat er mogelijk is om de bestanden (of database) te restoren. Dit zal dan gebeuren vanuit de server kopie. Hou er wel rekening mee dat er hoge kosten hieraan verbonden zittten, daar dit een behoorlijk karwei is!

Configuring Firewall

Make sure these ports are opened for all Parallels Plesk Panel services to work with a firewall:

• 20 for ftp-data;
• 21 for ftp;
• 22 for ssh;
• 25 for smtp;
• 53 for dns (TCP and UDP);
• 80 for http (web server and Parallels Plesk Panel updater);
• 106 for poppassd (for localhost only);
• 110 for pop3;
• 113 for auth;
• 143 for imap;
• 443 for https;
• 465 for smtps (dit was de oude poort om emails te versturen)
• 587 for mail message submission (aanbevolen poort om emails te versturen);
• 990 for ftps;
• 993 for imaps;
• 995 for pop3s;
• 3306 for mysql;
• 5224 for (outgoing connections only) plesk-license-update;
• 5432 for postgres;
• 8443 for plesk-https;
• 8880 for plesk-http;
• 9080 for tomcat;
• 5224 for license updates.

Het meerendeel van de klanten weet tegenwoordig wel hoe een nep / fake email eruit ziet. Gelukkig! Want je moet nooit ergens op klikken of geld/crypto overmaken.

Helaas blijkt het in de praktijk dat dit nog altijd niet voor iedereen duidelijk is en worden er (onnodige) tickets aangemaakt inzake dit onderwerp. Van al dit soort dergelijke emails is altijd 999 van de 1000 emails gewoonweg nep, dus niet echt. Als dit in een percentage neergezet moet worden, dan zijn van dit soort emails dus 99.9% altijd fake.

Hieronder een een drietal voorbelden van de nep emails die momenteel de ronde doen.

Hallo, hoe gaat het met jou? Ik weet het, het is vervelend om een gesprek te beginnen met slecht nieuws, maar ik kan niet anders.
Enkele maanden geleden heb ik toegang gekregen tot je apparaten die je gebruikt om op het internet te browsen.
Vervolgens heb ik al je internet activiteiten kunnen traceren. Hieronder kun je lezen hoe ik dit voor elkaar heb gekregen:
Allereerst heb ik van hackers de toegang tot meerdere e-mail accounts gekocht (tegenwoordig is dat een fluitje van een cent om dat online te doen).

I am aware one of your passphrase: <oud wachtwoord>. Lets get directly to point.
Not a single person has compensated me to investigate about you. You do not know me and you are probably wondering why you're getting this e-mail?
I actually installed a software on the adult vids (sex sites) site and you know what, you visited this web site to have fun (you know what I mean).
When you were viewing videos, your internet browser initiated working as a Remote control Desktop that has a key logger which provided me access to your display screen and also web cam.

Hi, victim.I write yоu becаusе I put а mаlware оn the wеb раge with porn whiсh yоu hаve visitеd.
My virus grаbbed all your рersonal infо аnd turnеd on yоur сamеrа which сaрtured the рroсеss оf your onаnism.
Just aftеr that the soft savеd yоur соntaсt list.I will dеlеte thе сompromising video and infо if you pаy me 999 USD in bitcoin.

Dit zijn stuk voor stuk allemaal nep emails. Ongeacht waar ze vandaan komen! Vaak lijkt het alsof ze van je eigen emailadres komen, maar dat is niet het geval!
Als je kijkt naar de headers, dan zal je zien, dat deze ergens anders vandaan komen; meestal een heel vreemd emailadres of rechtstreeks van een IP-adres (via een sciript verstuurd wellicht). Gewoon geen aandacht aan dit soort emails besteden en direct verwijderen. Ja, maar de email is van mij afkomstig? Neen, dat is niet zo. het mag dan wel zo lijken, maar dat is niet het geval. Het is dus gewoon onzin!

Ook zijn er vandaag talloze andere nep emails, waar men probeert om je geld, je rekeninggegevens of je privegegevens te onfutselen. Banken sturen je nooit, maar dan nooit een bericht dat je pas geblokkeerd is. T-Mobile verzoekt je nooit, maar dan ook nooit om te betalen in Bitcoin. Andere voorbeelden van nep emails die wij regelmatig voorbij zien komen zijn ondere andere van:

• ING (rekening geblokkeerd)
• ABN AMRO (betaalpas vervangen)
• Rabobank (pas geblokkeerd)
• T-Mobile (rekening, betalen met Bitcoin)
• PostNL (pakket gemist)
• CJIB (rijbewijs ingenomen)
• Intrum Justitia (spookfactuur met virus)
• ICS (creditcard beblokkeerd)

En ga zo maar door... Er zijn tientallen, zo niet honderden verschillende voorbeelden op te nomen (zie ook screenshots onderaan). Trap hier niet in! Klik nergens op! Vul nergens gegevens in naar aanleiding van dit soort emails. Dit geldt voor ieder emailaccount of emailadres die u heeft; of deze nu wel of niet bij ons gehost is. Verwijder dit soort emails altijd. Hiermee voorkomt u altijd problemen. En voorkomen is altijd beter dan genezen!

Controleer en/of raadpleeg bij twijfel de Fraudehelpdesk in dit soort gevallen. Deze partij heeft afgelopen jaar al meer dan 600.000 (!) meldingen gehad van verschillende nep emails. Of neem telefonisch contact op het bedrijf vermeld in de email (zoek het nummer online op en gebruik niet het nummer welke eventueel vermeld staat in de email). Dus u bent niet de eerste die een dergelijke email ontvangt en zeer zeker niet de laatste. Het is gewoonweg niet te voorkomen dat u dergelijke emails ontvangt. Spammers worden steeds slimmer en verzinnen nieuwe methoden om geld en/of gegevens van u te kunnen krijgen.

Nogmaals; 99.9% van al dit soort emails zijn gewoon nep. Trap er niet in en verwijder een dergelijke email.

Het heeft weinig zin/nut om hier een support ticket voor aan te maken, daar wij hier ook weinig tegen kunnen doen. Wij zullen u verwijzen naar dit KB artikel en u het advies meegeven om deze email te verwijderen. Meer kunnen wij niet doen helaas. Onze anti-spam software (Spamprotector) wordt iedere dag voorzien van nieuwe updates en herkenbaarheden in mogelijke spam, maar zoals u hierboven heeft kunnen lezen worden de spammers ook steeds slimmer en vinden telkens nieuwe manieren uit om voorbij dergelijke anti-spam filters te komen. En zolang dit nog rendabel voor hun is, zal dit ook wel zo blijven...

Hieronder een aantal zeer bekende voorbeelden van nep emails.

Er zijn twee mogelijkheden om uw website van te voren te bekijken (preview) op een Plesk omgeving.

De eerste mogelijkheid is alleen beschikbaar op de nieuwere Plesk servers. Dit is simpel te gebruiken, door in te loggen met de gegevens die u heeft ontvangen van ons op uw Plesk omgeving.
Eénmaal ingelogd, dan ziet u op het hoofdscherm (links in het midden) een icoon staan met de tekst "Preview". Als u hierop klikt, dan kunt u uw website alvast bekijken oftewel previewen via een tijdelijke link aangemaakt door de server. Deze functie is met name gemakkelijk voor nieuwe domeinnaam registraties en/of een verhuizing van een domeinnaam.

Er is ook een 2e methode (voor als u geen gebruik kunt maken van de "Preview"-functie) via een kleine aanpassing in de Windows "hosts"-file. Dit is, zoals wij het noemen, een echte oldskool oplossing die vroeger heel veel toegepast werd. Noteer als eerste het IP-adres van uw domeinnaam in de Plesk interface (onder "Hosting & DNS" > "DNS Settings"). Dit IP-adres zal als volgt opgebouwd zijn: 83.172.XX.XXX. Daarna volgt u de onderstaande stappen:

1. Op uw Windows computer opent u het hosts bestand (onder "C:\WINDOWS\system32\drivers\etc\hosts") met Kladblok.
2. Op de laatste regel geeft u het IP-nummer op en daarachter uw domeinnaam, dus bijvoorbeeld: 83.172.XX.XXX uwdomeinnaam.nl
3. Sla de wijzigingen op en herstert uw computer
4. Open nu met uw browser (Firefox, Chrome, Edge, etc.) uw website, bijvoorbeeld: uwdomeinnaam.nl
5. Nu wordt normaliter de website vanaf het nieuwe IP-adres getoond

Let op! Vergeet niet na het testen om de wijziging in het Windows hosts bestand ongedaan te maken! Dit kan u doen door de regel te verwijderen of een hashtag (#) ervoor te plaatsen.

Securing the /tmp Partition

It is recommended to run /tmp as separate partition and mount it with the noexec, nodev and nosuid options.

• The noexec option disables the executable file attribute within an entire file system, effectively preventing any files within that file system from being executed.
• The nodev option disallows creation of so-called device files with which you can get direct access to devices like the memory or disk
• The nosuid option disables the SUID file-attribute within an entire file system. This prevents SUID attacks on, say, the /tmp file system.

To secure the /tmp partition of your VPS or DPS server:

• run the command "mount" without parameters. If it contains the following line:
  
  /dev/simfs on /tmp type simfs (rw,nosuid,nodev,noexec,relatime,usrquota,grpquota)
  
  then the VPS / DPS has already a secured /tmp directory. All newer VPS / DPS are delivered with secured /tmp directory!
• If the /tmp directory is not yet configured, add the following line at the end of the file /etc/fstab :
  
  /usr/tmp /tmp simfs bind,rw,nosuid,nodev,noexec,relatime,usrquota,grpquota 0 0
• restart your VPS / DPS
  Please don't simply run a mount /tmp because programs like eg. MySQL or PHP might miss files they stored into the old /tmp directory. Only by restarting the server, all programs get aware of the new /tmp directory.

Op de markt zijn talloze verschillende goede (en ook slechte FTP) programma's beschikbaar. In dit voorbeeld hanteren wij Filezilla.
Filezilla is al jaren op de markt en is een gratis (en zeer betrouwbaar) FTP programma. Wanneer u dus bestanden wenst te uploaden en u heeft nog geen FTP programma, dan kunt u Filezilla hier downloaden.

U kan op diverse manieren connecteren naar uw website, waaronder;

• via de domeinnaam van uw hosting
• via het IP-adres van uw website
• via de hostname van de server

Het gemakkelijkste is uiteraard via de domeinnaam van uw webhosting. Wanneer uw domeinnaam www.helpburo.eu is, dan gebruikt u dus als naam: helpburo.eu.

Wanneer u Filezilla geinstalleerd en opgestart heeft, dan krijgt u venster te zien waarin vier (4) invulvelden te zien zijn:

• Host: uw domeinaam (zonder www of toevoegingen ervoor) in. Bijvoorbeeld: helpburo.eu (*)
• Username: is de gebruikersnaam gekoppeld aan uw FTP. Bijvoorbeeld: helpbeu
• Password: het wachtwoord gekoppeld aan de gebruikersnaam van uw FTP.
• Poort: deze is altijd standaard ingesteld op 21 (dit werkt voor alle servers zonder problemen).

(*) u kan bij "Host" ook het IP-adres van uw website invullen of de hostname (start met ns1 ervoor) van de server invullen op waar uw hostingaccount zich op bevindt. Klik hier om de hostname van de server te vinden.

Als het goed is bent u nu ingelogd op de FTP-omgeving van uw website. Mocht u niet kunnen connectoren, controleer dan of u de correcte gegevens gebruikt (hostnaam, gebruikersnaam, wachtwoord en/of poortnummer).
Ook kan het zijn dat uw (lokale) firewall op uw computer de verbinding blokkeert; controleer dit eveneens. Wanneer u 3x foutief inlogt, dan kunt u voor 15 minuten geblokkeerd worden. Dit is een extra beveiliging op onze servers om eventuele hackers tegen te gaan.

We gaan de handleiding nu opsplitsen voor Plesk en DirectAdmin, daar de uploadpaden anders zijn bij beide producten.

Plesk interface / controle paneel

In een Plesk omgeving dient u bestanden te uploaden in de map met de naam /httpdocs/. In andere mappen dient u niets te uploaden. Alles wat u in de map /httpdocs/ plaatst is ook zichtbaar op het internet.
Normaliter staat hier al een index.html of zelfs een index.php bestand in aangemaakt (of meerdere bestanden als u reeds iets heeft geupload in het verleden).
Wanneer dit de eerste keer is dat u connectie maakt naar de hosting van uw website, dan kunt u deze bestanden uiteraard verwijderen. Vanzelfsprekend dient u dit niet te doen als u reeds een website online heeft staan!

Kanttekening; u kan bij Plesk ook gebruik maken van de ingebouwde "File Manager" in de interface. Deze is simpeler qua gebruik maar ook qua functies, echter een prima simpel alternatief om kleine bestanden te uploaden of bestanden aan te passen.

DirectAdmin interface / controle paneel

Bij DirectAdmin moet u uw bestanden uploaden in de map met de naam /public_html/. In andere mappen dient u niks te uploaden. Alles wat u in deze map plaatst, zal ook direct zichtbaar zijn op het internet.
Normaliter staan hier al een paar standaard bestanden in, waaronder een index.html bestand. Of andere bestanden indien u al een keer bestanden heeft geupload.
Indien dit de eerste keer is dat u verbinding maakt naar de hosting van uw website, dan kunt u de bestanden onder /public_html/ uiteraard verwijderen. Als u reeds een website heeft staan, dan dient u deze bestanden niet te verwijderen!

Kanttekening; ook DirectAdmin heeft een standaard "File Manager" waarmee u simpele aanpassingen kunt verrichten aan (tekst)bestanden of verschillende bestanden kunt uploaden. Deze is vrij éénvoudig te gebruiken, maar daarnaast mist deze ook een aantal geavanceerde optie's die terug te vinden zijn in (bijvoorbeeld) FileZilla.

Uiteraard kan u de hierboven genoemde instellen ook toepassen op eventuele programmatuur die u gebruikt voor het onderhouden of aanpassen van uw website (bijvoorbeel Dreamweaver).

Welke rechten moeten bestanden en mappen standaard krijgen?

Standaard behoren alle bestanden chmod 644 te krijgen en mappen 755

Let op!!

Zet bestanden NOOIT op 777!!

Welke rechten moeten cgi-perl bestanden krijgen?

CGI en perl bestanden moeten chmod 755 krijgen.

Hoe pas ik de chmod rechten aan via een ftp programma?

De chmod rechten kunt u aanpassen via uw ftp programma door op het bestand of map met de rechtermuisknop te drukken en kiezen voor chmod of change attribute.

Hierbij vind u een chmod calculator:

Schrikbarend aantal (zeer) zwakke wachtwoorden
Helaas moeten we anno 2016 nog altijd constateren dat een groot aantal mensen en/of bedrijven gewoonweg te simpele wachtwoorden gebruiken voor hun websites, emailaddressen, cms, databases en ga zo maar verder.

Simpel gezegd; wachtwoorden die alleen bestaan uit woorden, alleen letters en/of cijfers zijn absoluut niet veilig meer tegenwoordig. Sterker nog, dit is al meer dan 8 jaar niet veilig! Ook het gebruik van straatnamen, postcodes, woonplaatsen en dergelijke zijn niet veilig. Enkele voorbeelden van wat wij, helaas, nog dagelijks tegenkomen qua wachtwoorden:

- vogels1
- aardbei
- 3306cj
- socrates
- qwerty123
- dummy1

Dit zijn dus wachtwoorden die absoluut niet veilig zijn en derhalve ook nooit gebruikt dienen en mogen worden. Indien u toch dit soort wachtwoorden blijft gebruiken of gewoonweg niet aanpast, dan is de kans aannemelijk dat uw account binnen de kortste keren gehackt is en uw (gevoelige) data en/of emails voor iedereen zichtbaar wordt.

Daarnaast kan uw account dan ook misbruikt worden om te spammen. Hier ondervinden wij niet alleen last van, maar ook de overige klanten op de desbetreffende server! Indien dit zich voor doet, dan zijn wij genoodzaakt het desbetreffende account compleet at te sluiten, dit om de overlast voor ons netwerk en andere te beperken.


Waarom zo streng of zelfs agressief optreden?
De reden hiervoor is simpel. Wij adviseren klanten al sinds jaar en dag om altijd sterke wachtwoorden te gebruiken. Indien een klant dit niet doet en vervolgens zijn/haar account wordt gehackt en vervolgens 100.000 (spam)emails worden verstuurd (of zelfs erger), dan wordt de integriteit van ons netwerk aangetast.

Daarnaast wordt de desbetreffende IP-range op de blacklist geplaatst en worden emails van andere klanten bij providers geweigerd. Dit allemaal omdat u heeft verzuimd om een sterk wachtwoord voor uw account aan te maken. Ook hier geldt voorkomen, is beter dan genezen...


Wat zijn dan sterke wachtwoorden?
Sterke wachtwoorden bestaan altijd uit een combinatie van kleine en grote letters, afgewisseld met getallen en speciale karakters. Als u zorgt dat u combinatie van deze gebruikt, dan weet u zeker dat u een sterk wachtwoord heeft. Het mogen best woorden zijn, maar dan wel dus gecombineerd met getallen en (vooral) speciale karakters.

Wel is het aan te bevelen om minimaal 1x per jaar uw wachtwoord(en) aan te passen voor nog meer zekerheid. Voorbeelden van sterke wachtwoorden:

- Ch75^SxhT33
- S0cR4t€s
- 855Jy975Rg#
- 8g7G9E3$$Dx
- Kjnn_8Dc3

Dit zijn enkele voorbeelden van sterke wachtwoorden. En op die manier bent u een stuk zekerder dat uw account niet zo snel gehackt zal worden. In ieder geval niet op basis van een sterk wachtwoord.

Wij snappen dat het onthouden van wachtwoorden vandaag de dag een stuk lastiger is geworden, zeker aangezien de complexiteit van de wachtwoorden enorm is toegenomen. Ook is er voor iedere website of webshop die u bezoekt inloggegevens nodig of ooit een keer ingevuld. Aangezien dit allemaal lastig is om te onthouden (opschrijven is ook niet te adviseren), willen wij u erop attenderen dat er een gratis oplossing bestaat, namelijk: LastPass.

Met LastPass kunt u eenvoudig uw wachtwoorden beheren, voor welke website dan ook. Op hun website wordt geadverteerd met de tekst: "LastPass onthoudt uw wachtwoorden, zodat u dat zelf niet hoeft te doen."
Zover wij kunnen hebben constateren is dit programma voor de meeste gebruikers volledig gratis, al bestaat er een mogelijkheid om tegen een minimaal bedrag te upgraden naar een premium account.

Wij verdienen hier helemaal niks aan en is gewoon een stukje vriendelijk advies, wanneer u moeite heeft met de enorme aantallen wachtwoorden te onthouden vandaag de dag.

U kan altijd oude Helpburo support tickets opnieuw openen, dus ook oude tickets die reeds gesloten zijn!

Maak aub hiervan gebruik, wanneer dit noodzakelijk is en maak geen nieuwe tickets aan over hetzelfde probleem of met een verwijzigng naar een ticket ID.
Anders wordt het zeer onduidelijk voor onze support medewerkers en daarnaast kan dit de verwerking van uw ticket vertragen.

Om oude en/of gelosten tickets opnieuw te openen, volgt u de 3 onderstaande simpele stappen:

1. Log in op uw Helpburo account
2. Klik vervolgens op de knop "Mijn tickets" (bovenaan)
3. Klik vervolgens op de knop "Afgehandelde tickets weergeven" (rechterkant)

Dat is alles! U ziet nu al uw oude tickets en u kan ieder ticket gewoon opnieuw openen door een reactie hierop te geven uiteraard.
Dus u hoeft geen nieuwe/extra tickets aan te maken over dezelfde probleem of vraag!

Ter extra verduidelijking ook een paar screenshots toegevoegd.

Stap 1:

Stap 2:

Stap 3:

Wat is impact van de websitesnelheid?

Zoals we allemaal wellicht al weten is dat Google veel waarde hecht aan snelle websites. In Google Webmaster Tools kun je dit bijvoorbeeld terug zien in de speedmetrics, maar je kunt dit ook terug zien in de Real User Measurement informatie in Google Analytics.

Hierin kun je zeer uitgebreide informatie vinden zoals redirection time, server response time en domain lookup time. Allemaal waardevolle informatie dus als het gaat om de snelheid van je website. Maar wat voor impact heeft de snelheid van je website op de website zelf en je bezoekers?

Gebruikerservaring van bezoekers

De laadtijd van de website heeft uiteraard direct impact op de gebruikerservaring. Veel bezoekers ergeren zich kapot aan een website die traag reageert of juist helemaal niet reageert. Dan kan opeens de website van de concurrent in één keer een stuk interessanter zijn.

Negatieve gebruikerservaring kan leiden tot een daling van je omzet of een daling van je bezoekers. Daarom hoort de focus van een website altijd te liggen bij de gebruikerservaring. Laadtijd heeft niet alleen effect op de gebruikerservaring, maar ook zaken zoals content, layout en functionaliteiten hebben invloed op de gebruikerservaring van je bezoekers.

Rankings in de zoekresultaten (Google)

Google heeft in 2010 al meegedeeld dat de snelheid van een website mee wordt genomen in de berekening van je positie in Google. Ook al zegt Matt Cutts dat het een kleine impact heeft op je rankings in de zoekresultaten, toch worden tragere websites minder gewaardeerd door Google.

Het vervelende is dat slechte hosting veel invloed heeft op de snelheid van je website. Je ziet uiteraard niet te wachten op 404- en 503-serverfouten. Slecht beheer van de server of slechte hosting kunnen dit allemaal veroorzaken en heeft uiteraard een negatief effect op de gebruikerservaring van bezoekers.

Indien je website hoge laadtijden heeft, zal het volgens Google niet heel veel verschil maken voor je positie in Google. Hierdoor zul je dus altijd veel organisch verkeer moeten ontvangen, echter de vraag is natuurlijk hoelang ze op de website willen blijven.

Wat houdt SEO-hosting precies in?

De term SEO-hosting is een term die steeds vaker voorkomt in de hostingwereld, maar voor de meeste mensen is SEO-hosting nog een volledig nieuw begrip. Vooral in Amerika is SEO-hosting ontzettend populair en ook steeds meer Nederlandse hostingpartijen lijken SEO-hosting aan willen bieden. Maar wat houdt SEO-hosting nu precies eigenlijk in?

Wanneer je meerdere website hebt is het een logische keuze om dit onder één of enkele hostingaanbieders te brengen. Hierdoor kun je eenvoudig het overzicht behouden en kun je natuurlijk ook eenvoudiger jouw websites beheren.

Maar wanneer je met SEO bezig gaat kan dit weer anders liggen. Als je bezig bent om via SEO de online vindbaarheid van je website te vergroten, dan kun je voor een SEO-strategie met landingspagina’s kiezen. Deze landingspagina’s kunnen allemaal een eigen domeinnaam hebben. Als je bijvoorbeeld gevonden wilt worden op SEO hosting, dan kan het domeinnaam seohosting.nl zeer interessant zijn.

Vervolgens zul je veel energie en tijd steken in deze landingspagina’s door SEO-teksten te gaan schrijven, websites te gaan bouwen en backlinks te gaan bouwen. Je wilt natuurlijk dat jouw websites en inspanningen goed beloond worden door Google. Maar wanneer je unieke websites maakt in dezelfde hostingomgeving, dan zul je daar niet veel kans op maken.

Wanneer je websites in dezelfde hostingomgeving bouwt, dan is de kans groot dat alle websites dezelfde ip-adressen hebben. Google ziet de unieke websites dat niet als een reguliere website zien, maar meer als een interne link naar uw website. En een interne link heeft veel minder waarde dan een externe link. 

Met SEO-hosting is dit gemakkelijk op te lossen, omdat je met SEO-hosting een aantal unieke ip-adressen ontvangt waar je jouw websites aan kunt koppelen. Hierdoor ziet Google het gewoon als unieke websites.

Wat zijn de nadelen van SEO-hosting?

Helaas zitten er ook een aantal nadelen aan SEO-hosting. Er is op dit moment nog niet echt een serieuze aanbieder van SEO-hosting in Nederland te vinden. De meeste aanbieders zitten in Amerika en om SEO-hosting te kunnen bestellen zul je dan vaak een PayPal-rekening of creditcard moeten hebben.

Daarnaast zijn de kosten voor SEO-hosting erg hoog. Dit komt omdat je een aantal unieke ip-adressen afneemt en deze zijn uiteraard duurder om te beheren, dan wanneer je bijvoorbeeld voor shares webhosting kiest.

5 handige tips voor een snelle website

Wanneer je een website voor e-commerce doeleinden gebruikt, dan weet je als geen andere dat je website goed moet presteren. Dat betekent dat je website aantrekkelijk en gebruiksvriendelijk moet zijn voor je bezoekers. Hierdoor zorg je ervoor dat bezoekers een langere tijd op je website doorbrengen.

En hierbij is snelheid misschien wel het belangrijkste, want hoe sneller pagina’s laden, hoe langer bezoekers op je website zullen blijven en meer pagina’s zullen bezoeken. Ook dit werkt weer positief door op de conversie van een website. Een snelle website zorgt niet voor een klein effect in de marge, maar kan een aanzienlijke bijdrage leveren aan de omzet. Hieronder vindt je 5 handige tips waarmee je een snelle website kunt  realiseren.

1. Maak een afweging tussen performance en design

Wanneer een bezoeker je website bezoekt, zal de browser van de bezoeker niet alleen informatie laden, maar ook bestanden en afbeeldingen. Dit zijn zaken die alles bijdragen aan een mooi design, maar het zijn ook zaken die het vertragen van het laden aanzienlijk kunnen beïnvloeden. Daarom is het verstandig om alle overbodige zaken weg te halen en vraag je altijd af of de extra content meerwaarde voor de bezoeker biedt.

2. Maak gebruik van caching

Gebruik maken van caching is de perfecte manier om de snelheid van je website te verbeteren. Met caching komt namelijk de inhoud van je website in statische bestanden op de computer van de bezoeker terecht. De volgende keer wanneer een bezoeker je website bezoekt, hoeft de bezoeker niet weer de originele data weer te downloaden van de server. Een klein deel van de website staat hierdoor al in cache op de computer van de bezoeker en dit vermindert weer aanzienlijk het dataverkeer van je hosting en bevordert uiteraard de snelheid.

Bij het verbeteren van de snelheid van je website is het verstandig om te weten hoe groot je website is. Wanneer je weet hoe groot je website precies is, kun je rekenen hoeveel servercapaciteit je precies nodig hebt.

Wanneer je onvoldoende capaciteit hebt dan zullen de webpagina’s langzamer gaan laden, dit kun je vooraf met je hostingprovider bespreken. Wanneer je een kleine website hebt met een blog, dan kun je simpel een klein hostingpakket kiezen. Maar wanneer je een grotere website hebt, dan kun je bijvoorbeeld beter met een dedicated en VPS server werken. Probeer hier dus bewust mee om te gaan en informeer hoe het precies zit.

4. Laad scripts als laatste

Wanneer je scripts als laatste laat laden, dan zal op deze manier alle content als eerst geladen worden, voordat de browser aan de scripts begint. De bezoeker krijgt als eerste de informatie te zien waar de bezoeker voor kwam en het vermindert ook de wachttijd voor het laden van je website.

5. Gebruik een content delivery network

Nu zul je denken, wat is een content delivery network? De locatie van een bezoeker die je website bezoeker is van grote invloed op de laadtijd van je pagina’s. Als je bezoekers van de andere kant van de wereld hebt, dan zal de data daar eerst helemaal heen moeten gaan. Dit kost natuurlijk wat tijd.

Maar een content delivery network helpt je hierbij door gestandaardiseerde delen van de website in een database onder te brengen over de hele wereld. Zo kan een browser je website ophalen vanuit een datacenter wat dichterbij zit en dit vermindert weer de vertraging.

Je kan je webbrowser (Internet Explorer, Firefox, Chrome, Safari, etc.) legen via de instellingen van de gebruikte webbrowser.
Een andere manier is om DNS-cache gewoon te legen op de computer zelf.

Dit is met name handig wanneer u een nieuw IP-nummer heeft toegewezen aan uw website.

Hieronder wordt uitgeleged hoe je dit kun doen in verschillende besturingssytemen.

In Windows
Open een opdacht prompt venster (Start > Uitvoeren) en geef daarin het commando "cmd".
Vervolgens krijgt u (normaliter) een zwart venster te zien. Geef hierin het commando "ipconfig /flushdns"

U krijgt daarna de volgende melding te zien: "Windows IP configuration successfully flushed the DNS Resolver Cache"
U heeft nu de DNS-cache geleegd van uw Windows besturingssysteem.

In Mac OS X
Open het programma terminal (Programma's > Hulpprogramma's) en geef het commando in de DNS-cache te flushen.
Het commando is verschillend bij verschillende versies van Mac OS X.

• Mountain Lion of Lion: sudo killall -HUP mDNSResponder
• Snow Leopard: dscacheutil -flushcache
• Leopard en ouder: lookupd -flushcache

Indien er gevraagd wordt om een wachtwoord, dan dient u het beheerders wachtwoord in te geven van uw computer.
U heeft nu de DNS-cache geleegd op uw Mac OS X besturingssysteem.

In Linux
Open een terminal als root of typ eerst sudo voordat je het commando om de DNS-cache te legen ingeeft.
Geef vervolgens de volgende commando's in om de DNS te flushen:

• sudo /etc/init.d/dns-clean
• service network-manager restart

U heeft nu de DNS-cache geleegd van uw Linux besturingssysteem.

We merken dat er regelmatig reacties op support tickets binnenkomen vanaf een ander e-mailadres dan het e-mailadres dat geregistreerd is bij Helpburo. Als dit andere e-mailadres niet gekoppeld is aan uw Helpburo-account, wordt de reactie helaas niet toegevoegd aan het ticket. Dit kan ervoor zorgen dat uw reactie niet gezien wordt door ons support team.

Het is belangrijk om bij het beantwoorden van een support ticket altijd hetzelfde e-mailadres te gebruiken waarmee het ticket is aangemaakt of waaraan het is geadresseerd. Dit wordt ook vermeld bij het aanmaken van een support ticket en in de automatische bevestiging. Daarnaast is het cruciaal om het ticket ID in de onderwerpregel te laten staan.

Helaas zien we dat dit nog niet altijd gebeurt. Bijvoorbeeld, als een ticket wordt aangemaakt via info@pietjepuk.nl en later wordt beantwoord via pietjepuk@gmail.com, dan herkent Helpburo dit e-mailadres niet en wordt de reactie niet toegevoegd aan het ticket.

Dit probleem kunt u eenvoudig voorkomen door extra e-mailadressen toe te voegen onder uw profielinstellingen op Helpburo, of door gewoonweg het juiste e-mailadres te gebruiken bij het beantwoorden van een support ticket per e-mail.

Zie ook screenshots in de bijlage voor meer duidelijkheid.

Door de jaren heen is de prijs van Installatron gestegen. Tot op heden hebben wij deze prijsstijging echter niet doorberekend aan klanten met een eigen server (VPS/DPS). Gezien de beperkte kennis die wij hebben over Installatron en de complexiteit van het platform, raden wij aan om bij problemen direct contact op te nemen met de supportafdeling van Installatron.

Mogelijke problemen kunnen zijn: problemen met het installeren of updaten van applicaties, beschikbaarheid van alleen oudere versies, en problemen bij het klonen van websites binnen Installatron. Installatron wordt steeds uitgebreider, evenals de servers en controlepanelen (zoals DirectAdmin en Plesk). Daarom hebben wij besloten onze expertise te beperken tot servergerelateerde kwesties. Voor serieuze problemen met Installatron kunt u direct een supportticket aanmaken bij Installatron via deze link.

Voor problemen met niet (automatisch) verlengde licenties voor Installatron kunt u uiteraard nog steeds een supportticket bij ons indienen. Dit geldt ook voor reguliere hostingklanten.

Op dit moment circuleert er nieuws inzake een kwetsbaarheid m.b.t. Apache Log4j.

Alle (opgeleverde) servers met Plesk of DirectAdmin maken geen gebruik hiervan en dus vormt deze kwetsbaarheid geen risico.
Dus wanneer u een server heeft met Plesk of DirectAdmin, dan hoeft u zich geen zorgen te maken.

De enige servers die (in theorie) een probleem hier mee kunnen hebben zijn zogenaamde plain servers (LAMP). Dit zijn specifieke servers en worden alleen door klanten besteld met technische Linux kennis.
Dit zijn "kale" servers zonder een interface (zoals Plesk of DirectAdmin) en worden door ons alleen voorzien van Linux, Apache, MySQL en PHP (vandaar de naam LAMP). De klanten die dergelijke servers afnemen zijn zelf verantwoordelijk voor wat men installeert op zijn/haar server. Normaliter maken dergelijke servers ook geen gebruik van Apache Log4j, maar het kan zijn doordat u een bepaalde applicatie heeft geinstalleerd op uw server die deze functie wel gebruikt. In dat geval raden wij u aan om deze kwetsbaarheid te dichten. Wij leveren nagenoeg nauwelijks tot geen support op zogenaamde plain (= LAMP) servers, daar hier ontelbare configuratie mogelijkheden voor zijn.

Voor de goede orde; heeft u een server (of hostingaccount) met een Plesk interface of met een DirectAdmin interface, dan heeft u geen last van de Apache Log4j kwetsbaarheid!

Wanneer u gebruik maakt van CloudFlare diensten voor uw website en/of server (via de nameservers van CloudFlare), dan dient u altijd "DDoS protection" in te schakelen.
Dit voorkomt niet alleen DDoS aanvallen, maar zorgt er ook voor dat uw website (en server) niet offline gaat door duizenden queries en/of connecties die getunneld worden via CloudFlare!

Dit is zeer gemakkelijk in te stellen binnen CloudFlare. Volg hiervoor de onderstaande stappen:

• Log in op CloudFlare
• Ga naar de domeinnaam in kwestie
• Open het "Security"-menu (linkerzijde)
• Klik nu op "DDoS"

U krijgt nu een nieuw scherm te zien, namelijk:

Schakel in ieder geval "HTTP DDoS attack protection" in. U kan deze instellen door op "Configure" te klikken.
Kies op de nieuwe pagina de volgende opties:

• Ruleset action: Default
• Ruleset sensitivity: Default

Vervolgens klikt u op de "Save"-knop (rechtsonderin).

Nog steeds een DDoS aanval?
Bij zeer zware DDoS aanvallen en wanneer het bovenstaande niet helpt (website continue niet bereikbaar, laad langzaam of server offline) dan zal u de optie "Under Attack Mode" moeten activeren binnen CloudFlare. Dit is eveneens vrij snel in te stellen, namelijk:

• Selecteer (indien nodig) de domeinnaam in kwestie
• Klik nu op "Overview" (linkerzijde)
• Activeer nu (aan de rechterkant) de optie: Under Attack Mode

Nu zal u moeten wachten tot de DDoS aanval afgelopen is. Dit kan enkele minuten zijn, maar kan ook uren duren. Helaas is hier geen vast antwoord op te vinden.

Wellicht is het wel verstandig om de oorzaak te achterhalen van de DDoS aanval op uw website (of server). De voornaamste redenen zijn:

• slecht onderhouden website (al geruime tijd niet voorzien van updates)
• slecht of helemaal niet beveiligde (Wordpress) website
• oude en te gemakkelijke wachtwoorden (website, email, database, etc.)
• mail scripts of comment systeem (o.a. bij Wordpress) misbruik
• u heeft kwaad bloed gezet bij een ander persoon/bedrijf

Zoals u kunt constateren zijn er vele redenen die voor een DDoS aanval kunnen zorgen op uw website of server. De hierboven genoemde redenen zijn de meest voorkomende, al zijn er natuurlijk ook nog andere (minder vaak voorkomende) redenen voor een mogelijke DDoS aanval.

Indien u wenst kunnen wij een technisch onderzoek opstarten tegen tech kosten (tarief afhankelijk van tijdsperiode). Er wordt altijd minimaal één uur gerekend voor een dergelijk onderzoek. Indien u dit wenst, dan zal u een support ticket moeten aanmaken op Helpburo. Vermeld in het ticket dan zoveel mogelijk informatie, denk aan; inloggegevens, periode van DDoS aanval, etc. Hoe meer informatie u kan aanleveren, hoe sneller de oorzaak achterhaald kan worden en hoe lager de tech kosten uiteindelijk zullen zijn.

Wij hebben de afgelopen jaren al meerdere keren vermeld (via websites, nieuwsbrieven, Kennisbank artikelen en in diverse support tickets) dat het absoluut noodzakelijk is om formulieren altijd te beveiligen met een captcha code. Er is géén enkele reden om dit niet te doen!

Wanneer dit niet gedaan wordt, dan zal het formulier altijd misbruikt worden om spam te versturen. Met als resultaat dat de mail server op een zwarte lijst komt te staan en u (en mogelijk ook andere klanten) geen emails meer kunnen versturen. U dient dus altijd formulieren te beveiligen hiertegen! Doet u dit niet, dan zetten wij de sendmail functie t.b.v. de PHP uit inzake uw website! Wij hebben hier al talloze keren op gehamerd om dergelijke formulieren te beveiligen.

Welke formulieren dienen beveiligd te worden? Ieder formulier waar een emailadres op staat dient beveiligd te worden. Denk bijvoorbeeld aan:

• contact formulieren
• inschrijving nieuwsbrief
• reactie / reageer pagina's (ook wel comments genoemd)
• overig formulieren waar een emailadres opgegeven moet worden

Dergelijke formulieren dienen altijd afgschermd te worden. Nogmaals; er is géén enkele reden om dit niet te doen. Doet u dit niet, dan zullen wij bij misbruik de PHP sendmail functie in zijn geheel uitschakelen voor uw website. Dat wil zeggen dat men geen formulieren meer kan verzenden (en dus ook geen spam). Ondanks al onze waarschuwingen en meldingen zijn er nog altijd veel te veel websites die deze beveiliging niet doorvoeren. Resultaat? De mailserver komt op de zwarte lijst te staan en (overige) klanten kunnen geen emails meer versturen. Vervolgens kunnen wij een de-listing aanvragen voor de mailserver (wat vaak 24 uur duurt). Dit kost ons niet alleen een hoop tijd en geld, maar ook gaat dit iedere keer ten koste van de reputatie van onze IP-ranges.

Hier ook een voorbeeld van een onbeveiligd (contact) formulier:

En ja, dit formulier werd ook misbruikt om spam te versturen (enkele honderden spam emails). Ook van deze website hebben wij de PHP sendmail functie compleet uitgezet. Hierdoor werkt het contact formulier niet meer, maar zal deze ook geen spam meer versturen met alle problematiek van dien.

Dit betreft nota bene een Wordpress website, waar het heel gemakkelijk is om dergelijke formulieren kinderlijk éénvoudig af te schermen via een captcha code of een andere beveiliging. Hiervoor zijn een legio aan verschillende Wordpress plugins voor beschikbaar om dit gemakkelijk en snel te kunnen realiseren.

Ook voor "losse" formulieren (dus niet gekoppeld aan een CMS, zoals Wordpress) zijn er verschillende oplossingen beschikbaar. Zo is de meest bekendste van Google, met de naam reCAPTCHA. Zie voor meer informatie hier. Dus er is absoluut geen enkele reden om welk formulier dan ook niet te beveiligen! En nogmaals; indien uw website ons en overige klanten (herhaaldelijk) problemen bezorgd, dan zetten wij vandaag de dag gewoon de PHP sendmail functie uit. Het kost ons gewoonweg teveel tijd en energie om klanten hierop individueel te attenderen en dan af te wachten totdat er een oplossing wordt toegepast. Sterker nog; onze ervaring leert ons, dat klanten die verzuimen om formulieren te beveiligen, niet eens merken dat hun contact formulier niet meer werkt c.q. functioneert. Ook dat zegt al voldoende...

Resumé; iedere vorm van een formulier waar email mee verstuurd wordt, dient beveiligd te worden. Wordt dit niet gedaan en wij constateren misbruik (in de vorm van spam), dan zetten wij de PHP sendmail functie direct uit. Dit voorkomt niet alleen een hoop werk en kosten voor ons, maar voorkomt ook ellende voor andere klanten.

Doorverwijzing naar dit artikel via support ticket

Indien u naar aanleiding van uw support ticket naar dit Kennisbank artikel bent doorverwezen, dan is de kans zeer aannemelijk dat het formulier op uw website (herhaaldelijk) misbruikt werd/wordt om spam te versturen. Als een gevolg hiervan (en zoals u hierboven ook al heeft kunnen lezen) hebben wij dus de PHP sendmail functie compleet uitgeschakeld voor uw domein en/of webhostingaccount.

Dit zal pas wederom geactiveerd worden als u (of uw website bouwer c.q. beheerder) het probleem heeft opgelost en het (contact) formulier beveiligd heeft. Wanneer dit gebeurd is, dan kan u dit aangeven in het support ticket. Wanneer wij constateren dat dit daadwerkelijk is gebeurd en dat het formulier inderdaad is beveiligd, dan zullen wij wederom de PHP sendmail functie weer inschakelen voor uw domein en/of website.

Problemen met email verzenden en/of ontvangen

Onbeveiligde contact formulieren en/of uitgeschakelde PHP sendmail functie hebben niks te maken met problemen bij het verzenden of ontvangen van email via een email programma (op computer, laptop, tablet, telefoon e.d.) of via webmail. Indien u puur en alleen problemen heeft met het verzenden en/of ontvangen van email, dan raden wij u aan om één van de andere Kennisbank artikelen te raadplegen hierover.

Vaak is het probleem dat u verkeerde of oudere instellingen gebruikt, die vandaag de dag niet meer goed functioneren of onveilig zijn.

Tags: contact formulier, sendmail php, formulieren, onbeveiligde formulieren, captch, recaptcha

Ons online support systeem (Helpburo.eu) is 24/7 bereikbaar. Dit online support systeem wordt daarnaast ook direct gebruikt door onze technici.

Dus indien u problemen ondervindt met uw emailadres, webhosting, server of wat dan ook (wat gerelateerd is aan onze diensten en/of producten), dan kan u hiervoor altijd een support ticket voor aanmaken. Een support ticket werkt vaak vele malen sneller dan bellen of een email sturen, daar wij vaak aanvullende informatie nodig hebben bij eventuele problemen. Dit laatste is behoorlijk lastig om dit via de telefoon te doen uiteraard. Ook kan het zijn dat er screenshots worden gevraagd inzake het probleem. Ook dit is moeilijk per telefoon te realiseren. Dus vandaar dat een support ticket altijd de voorkeur heeft.

Hou ook rekening met het volgende:

Wanneer u een support ticket per email wilt beantwoorden, gebruik dan altijd hetzelfde emailadres waar u het support ticket mee heeft aangemaakt of waar deze aan geaddresseerd is. Doet u dit niet, dan wordt uw reactie niet toegevoegd aan het ticket en zien wij deze dus niet! En laat ook altijd het ticket ID in de onderwerpregel staan.

Indien een support ticket is opgelost, dan wordt deze gesloten door ons. Een support ticket wordt ook automatisch gesloten wanneer er géén reactie komt binnen afzienbare tijd. Uiteraard kan u altijd gesloten tickets opnieuw openen. U hoeft dus niet een nieuw ticket aan te maken inzake hetzelfde probleem. Wanneer dit ticket is gesloten, dan kan u deze hier opnieuw openen of door te reageren via email.

Dus wanneer u op een ticket gaat antwoorden met een ander emailadres dan in het systeem bekend is, dan wordt uw reactie niet toegevoegd aan het support ticket en zal deze niet door ons gezien worden! Bij problemen inzake de email kan u altijd uw support tickets ook online inzien; dit is sowieso de aanbevolen methode (daar reacties direct worden toegevoegd). Indien u toch een support ticket per email beantwoord, dan dient dit wel gekoppeld te staan aan uw account op Helpburo.

U kan extra emailadressen (zoals bijvoorbeeld Gmail, Outlook e.d.) gewoon toevoegen aan uw account op Helpburo. Log hiervoor in op Helpburo en ga vervolgens naar het "Mijn profiel"-tabblad. Onderaan op de nieuwe pagina kunt u extra emailadressen toevoegen. Wanneer u hier emailadressen toevoegd, dan kan u voortaan ook daarmee antwoorden op support tickets. Alleen dan kan u dus ook antwoorden met andere emailadressen op (bestaande) support tickets.

Verder is het altijd raadzaam om de kennisbank artikelen te raadplegen inzake eventuele problemen met uw website, email, hostingaccount, server of overige door ons geleverde diensten en/of producten. Vaak zijn standaard problemen of veelvoorkomende problemen al opgelost en staat dit vermeld in een dergelijke kennisbank artikel. Zo zijn 9 van de 10 emailproblemen vandaag te wijten aan verkeerde of oude instellingen. Ook tijdens het aanmaken van een support ticket geeft het Helpburo online support systeem al kennisbank suggesties aan. Controleer deze suggesties dan ook. Dit scheelt ons onnodige support tickets en kunnen wij support blijven leveren voor (echte) urgente zaken en/of problemen.

Wanneer wij een support ticket in behandeling hebben en/of ermee bezig zijn, ga dan niet de urgentie van het ticket veranderen. Dit heeft geen effect en het zal echt niet de zaak bespoedigen. Wij pakken vrijwel altijd support tickets direct op (zeker tijdens kantooruren). Daarnaast worden tickets met een verkeerde urgentie niet eerder afgehandeld. Dus als u bijvoorbeeld erachter komt na een dag dat uw website niet functioneert of dergelijke, ga dan geen support ticket inschieten met "Critical", dit werkt averechts en zorgt er alleen maar voor dat het langer duurt voordat wij uw ticket in behandeling nemen. Wij krijgen per dag tussen de 20 en 50 support tickets binnen, dus dergelijke tickets (met een verkeerde urgentie) worden vervolgens onderaan geplaatst. Hou hier rekening mee aub.

Tot slot; het is natuurlijk altijd aan te bevelen dat men de nieuwspagina (met mededelingen) controleert, alvorens met een support ticket inschiet dat een website of emailadres niet functioneert. Er is altijd een kans dat met meer dan 1000 actieve servers er ergens een technisch probleem is. Als wij dit constateren (via onze monitoring software), dan pakken wij dit altijd direct op en (indien noodzakelijk) plaatsen wij hier ook een melding van op onze nieuwspagina's.