Bekijk Volledige Versie : Nieuwe ICANN regels: ERRP, contactgegevens verificatie
Wordt een beetje moe van de nieuwe ICANN regels voor internationale GTLD domeinen.
Eerst kwam de regel dat een ERRP e-mail bericht verstuurd moet worden aan de klant als zijn domein binnenkort verloopt.
De partij aan wie wij het registeren van .com domeinen hebben uitbesteed verstuurt deze berichten ook doodleuk als ingesteld staat dat het domein automatisch verlengd moet worden aan het einde van de periode.
Levert onterechte paniek bij de klant op, die het (Engelstalige) bericht niet goed begrijpt, en denkt dat wij zijn domein vergeten zijn te verlengen.
En vandaag ontvingen we bericht dat vanaf 1 januari 2014 een e-mail bericht met bevestigingslink wordt verstuurd aan het e-mail adres van de klant op het moment dat we in het systeem van de leverancier een nieuw contactpersoon aanmaken of wijzigen.
Dit onder het mom dat dit vereist is om aan de nieuwe ICANN contact verification regels te voldoen: http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.htm#whois-accuracy
Op het moment dat een nieuwe klant zich op onze website aanmeld wordt het e-mail adres al door ons eigen systeem gecontroleerd d.m.v. het sturen van een e-mail met bevestigingslink.
Een beetje dubbelop en erg klantonvriendelijk indien dit een tweede maal -door onze leverancier- zou moeten gebeuren op het moment dat de klant een .com registreert.
Doen andere ICANN accredited registrars hier ook zo moeilijk over, of zijn er ook leveranciers met een wat pragmatischere aanpak die het controlleren van de gegevens wel nog gewoon aan de reseller over laten zoals voorheen?
Waarschijnlijk gebruiken we dezelfde partij (ik herken de situatie incl. het bericht vandaag). De ERRP berichten zijn inmiddels wel (deels) aan te passen, maar de logica om ze ook te sturen als auto-renew aan staat zijn wij niet blij mee. Helemaal als dit niet duidelijk in het bericht staat (en de taal van berichten wil je eigenlijk per domein in kunnen stellen ivm klanten in meerdere landen/taalvoorkeuren).
Mijn vermoeden is dat er met bepaalde ICANN accredited registrars wel te praten is om dit te regelen. Morgen eens even met een Nederlandse partij contact opnemen om te kijken of ze inmiddels een vervanger kunnen zijn mbt de diensten die we er gebruiken (eind november heb ik nog gehoord dat ze voor 1 januari het laatste puntje zouden hebben geregeld).
Onze partij is daar een stuk beter mee (wij zijn zelf ICANN geaccrediteerd maar resellen ook nog veel extensies via ResellerClub). Zij bieden aan om (volledig customizable) emails voor je te sturen of om dat gewoon uit te schakelen en je dat zelf laten regelen (zolang je je maar aan de regels houdt - zij willen ook geen gezeur met ICANN).
Ik zou erg uitkijken met het vergelijken van registrars op dit moment, bij veel partijen is het nog niet helemaal duidelijk wat de gevolgen van RAA 2013 zijn of ze vallen er (nog) niet onder omdat ze bijvoorbeeld geen nieuwe gTLDs aanbieden. Sowieso gaan de bepalingen pas in de tweede helft van 2014 gelden voor domeinnamen onder de oude gTLDs.
Bij ResellerClub zie ik bijvoorbeeld maar 1 posting op hun blog over RAA 2013 [1] en dat gaat over het nieuwe whois-format, iets dat bij sommige andere registrars al weken geleden live is gezet. Hoe weten we dat ze niet simpelweg laat zijn met implementeren/informeren?
[1] http://blog.resellerclub.com/2013/11/28/impact-of-the-2013-icann-registrar-accreditation-agreement/
Onze partij is daar een stuk beter mee (wij zijn zelf ICANN geaccrediteerd maar resellen ook nog veel extensies via ResellerClub). Zij bieden aan om (volledig customizable) emails voor je te sturen of om dat gewoon uit te schakelen en je dat zelf laten regelen (zolang je je maar aan de regels houdt - zij willen ook geen gezeur met ICANN).
Ik zou erg uitkijken met het vergelijken van registrars op dit moment, bij veel partijen is het nog niet helemaal duidelijk wat de gevolgen van RAA 2013 zijn (...)
En inderdaad, op http://blog.resellerclub.com/2013/12/12/impact-of-the-2013-raa-whois-info-verification/ staat nu toch iets heel anders te lezen:
"2. The verification email will be sent out from the Reseller’s email address. It shall be a compulsory system mail, which shall not be customised or turned off."
En inderdaad, op http://blog.resellerclub.com/2013/12/12/impact-of-the-2013-raa-whois-info-verification/ staat nu toch iets heel anders te lezen:
"2. The verification email will be sent out from the Reseller’s email address. It shall be a compulsory system mail, which shall not be customised or turned off."
Altijd jammer dat je er nog niet eens een paar eigen regels tekst in kunt zetten om klanten gerust te stellen (of in ieder geval de juiste taal te gebruiken) en daarnaast is het ook jammer dat ze de afzender zetten naar een vast email adres. Een afzender afhankelijk van de domeinnaam zou veel mooier zijn.
If the registrant does not complete the verification in the allotted time,
we shall modify the name servers of the domain name to stop its resolution
and point the domain name to a white-labeled holding page. This page will
simply instruct that the domain name has been disabled due to the Registrant
information being verified, and instruct the Registrant to contact their
service provider to make it active again.
Blokkade indien niet binnen 15 dagen geverifieerd na registratie of wijziging van de contactgegevens.
Vraag me af of dat laatste niet averechts werkt, en partijen niet aanmoedigt om dan maar gewoon helemaal geen wijzigingen meer door te geven.
maxnet ik heb psies hetzelfde, klanten raken in paniek en wij kunnen elke keer uitleggen dat ze mail van het ICANN moeten negeren dat er niets aan de hand is en dat de domeinnamen gewoon verlengt worden. Als er nog meer onduidelijkheid komt wordt het dus alleen nog maar erger :( ik hoop dat hier door ALLE partijen snel wat aan gedaan wordt, anders gaat iedereen zijn eigen email adres invullen om dit af te vangen. En dat lijkt me niet de bedoeling!
Altijd jammer dat je er nog niet eens een paar eigen regels tekst in kunt zetten om klanten gerust te stellen (of in ieder geval de juiste taal te gebruiken) (...)
Niet voor het een of ander, maar bij de registrar waar TS over klaagde kan dat nu juist wel.
Niet voor het een of ander, maar bij de registrar waar TS over klaagde kan dat nu juist wel.
Als ik het goed heb gebruiken wij dezelfde partij (of er moeten 2 ICANN registrars op dezelfde dag een mailing met dezelfde strekking verstuurd hebben). Hier kun je het niet per domeinnaam aangeven, enkel per account bij hun. Dit is zeer jammer aangezien je hierdoor relatief lastig klanten enkel de juiste taal kunt mailen en je het ook niet echt kunt branden per gebruikte handelsnaam (of bij resellers de branding op naam van die reseller kunt zetten). De ERRP berichten zijn inderdaad inmiddels wel (deels) aan te passen, de mogelijkheden hier zijn echter nog steeds beperkt (een volledig nieuw bericht aanleveren kan ook, dit kost wel een paar honderd euro als ik me niet vergis).
Ten minste ik kan de optie om het per domeinnaam in te stellen nergens vinden.
Als ik het goed heb gebruiken wij dezelfde partij (of er moeten 2 ICANN registrars op dezelfde dag een mailing met dezelfde strekking verstuurd hebben). Hier kun je het niet per domeinnaam aangeven, enkel per account bij hun.
Ah ja, dat klopt. Dat is voor onze situatie geen groot probleem maar ik kan me voorstellen dat het fijn zou zijn om dat ook per domein te mogen doen. Ik denk dat dit niet kan omdat ze de teksten toch handmatig lijken te controleren (of in ieder geval richting ICANN moeten kunnen verkopen dat ze dat doen).
Mijn punt (ook met eerdere berichten) was eigenlijk dat de registrar waar in eerste instantie over wordt geklaagd het juist helemaal niet onaardig doet, binnen de regels die ICANN stelt. Je kunt dan wel op zoek gaan naar een registrar die bereid is de ICANN-regels te buigen maar ik denk dat je zo'n partij niet snel vindt. Bovendien vraag ik me af of je bij zo'n registrar wel goed en veilig zit.
Over het nut van de ICANN-regels valt verder wel te discussiëren, maar dit is daar eigenlijk niet de plaats voor. Dan kun je beter een delegatie sturen naar een ICANN-meeting en rechtstreeks met het board in discussie proberen te gaan (iets wat ongetwijfeld al is gebeurd trouwens).
Mijn punt (ook met eerdere berichten) was eigenlijk dat de registrar waar in eerste instantie over wordt geklaagd het juist helemaal niet onaardig doet, binnen de regels die ICANN stelt. Je kunt dan wel op zoek gaan naar een registrar die bereid is de ICANN-regels te buigen maar ik denk dat je zo'n partij niet snel vindt. Bovendien vraag ik me af of je bij zo'n registrar wel goed en veilig zit.
De teksten hoeven niet telkens anders te zijn wat mij betreft, enkel het afzender adres en een variabele voor de handelsnaam zou al genoeg zijn. Eventueel nog 2 versies en het is helemaal een luxe positie binnen de regels (als de ene naam werkt met standaard auto-renew aan en de ander met standaard auto-renew uit). Daarnaast is een taal kiezen per domeinnaam wel wenselijk, dit maakt het net wat handiger voor klanten (naast het maken van 1 bericht in meerdere talen onder elkaar). Dit lijkt mij niet in strijd met de ICANN regels (het lijkt me zelfs in lijn met de gedachte aangezien mogelijk niet iedere registrant de Engelse taal machtig is en daarmee nog niet geïnformeerd wordt). Wij hebben het nu nog op hun standaard instellingen staan en benaderen ze over een tijdje wel weer om het hier eens over te hebben.
Wij hebben in ieder geval goed contact met ze en hebben na kort kijken naar alternatieven besloten bij ze te blijven en er juist nog meer naar toe te verhuizen.
Altijd jammer dat je er nog niet eens een paar eigen regels tekst in kunt zetten om klanten gerust te stellen (of in ieder geval de juiste taal te gebruiken)
Mag dat eigenlijk wel? Bij de meeste communicatie over een domeinnaam moet je dit namelijk in "dezelfde taal waarin de registratieovereenkomst ook is opgesteld" doen. Dan verplichten ze je dus niet alleen om je (voornamelijk) Nederlandstalige klanten Engelstalige emails te laten ontvangen waar je geen aan eigen informatie in kwijt kunt maar ook om klanten een Engelstalige registratieoverenkomst te laten tekenen. Dit gaat ResellerClub klanten kosten denk ik.
Mag dat eigenlijk wel? Bij de meeste communicatie over een domeinnaam moet je dit namelijk in "dezelfde taal waarin de registratieovereenkomst ook is opgesteld" doen.
Goed punt.
2.1.3. Notifications of expiration may be presented in one or more languages, but must be provided in the language of the registration agreement and must be communicated in a manner, such as by email, that does not require affirmative action to receive the notification.
Instructies in de taal van de overeenkomst moeten er in ieder geval bij zitten.
Hoewel je meerdere talen in 1 bericht kan proppen.
Heeft iemand al 'last' van deze nieuwe RAA van ICANN?
Onze registrar gaat pas komende maandag dit implementeren.
Hoe gaan jullie dan ook met de (domein) resellers? Wij kunnen ook maar 1 e-mail (template) verzenden vanuit onze registrar, dus als we rekening houden met de resellers, mogen wij onze eigen bedrijfsnaam nergens noemen. Maar dan lijkt zo een e-mail heel erg op een spam (en wellicht zal een % van de mails uiteraard in de spam terecht komen).
Tot slot, wat gebeurd er indien klant (OwnerC) deze e-mail niet leest / linkje klikt? Volgens onze registrar (en van anderen zo te lezen) wordt domein gedeactiveerd. Bijvoorbeeld bij Enom 'kapen' ze DNS en verwijzen ze domeinnaam naar een 'niet bevestigd domein' URL / pagina?! Mag dat ook zomaar? Zijn er kosten aan de 'heractivatie' verbonden? Wat als OwnerC domein nooit bevestigd - krijgen we geld terug?! Oh oh oh zo veel vragen :)
Al met al, vind ik het zeer bijzonder slechte zet van ICANN!
Ik vind het, op zijn minst - bijzonder - dat er geen enkele reactie gekomen is?
Wellicht moet ik nog 2 dagen geduld hebben, tot dat domeinnamen daadwerkelijk offline gehaald worden?
Ik kwam trouwens nog paar 'nieuwe' zaken tegen m.b.t. deze RAA wijziging.
1. Alle domeinnamen gerelateerd aan de contact handle komen te vervallen bij het niet tijdig klikken op de link in de e-mail;
dus mocht een klant 40 domeinen hebben en er wordt iets gewijzigd aan de handle (bijvoorbeeld bedrijfsnaam), dan dient klant per e-mail binnen 15 dagen dat te bevestigen.
Mocht hij dat dus niet tijdig doen, komen alle 40 domeinnamen 'op zwart' te staan.
2. Kip en ei verhaal;
stel klant verhuisd zijn domein. Dan dient hij ook per e-mail dat te akkoorderen.
Maar - zijn e-mail adres is ook gebaseerd op de net verhuisde domein. Na 15 dagen gaat alles op zwart, waarbij ook MX (in het geval dat DNS wordt overgenomen door de registry).
Dan kan klant ook niet meer bij de e-mail. In theorie, zou dan:
1) klant bellen met de hoster om e-mail gewijzigd te krijgen;
2) nieuwe mail ontvangen op nieuwe adres;
3) domein bevestigen / heractiveren;
4) hoster bellen om e-mail adres terug te zetten in de whois;
5) nogmaals e-mail ontvangen en deze ook bevestigen.
Briljant!
3. Hoe veel van de verzonden e-mails zullen in de spam terecht komen? Zoals iemand netjes heeft opgemerkt op de webhostingtalk.com - registry (kan) email verzenden namens hoster. Echter, SPF record ontbreekt dan op de server dat mails gaat verzenden - dus kans is groot / groter dat mail in de spam terecht komt.
4. Onze partij biedt geen mogelijkheid om uitgaande e-mails aan te passen. Wij kunnen alleen afzender naam / e-mail beinvloeden. Dus alle mails zijn standaard :(
En dan blijf ik alsnog verbaasd hoe weinig 'ophef' te vinden is op het internet... Of maak ik me te druk?
dennis0162
27/01/14, 16:15
Kleine topic kick.
Hoe loopt dit bij jullie?
Wij blijven er maar achteraan mailen dat klanten hun contact gegevens moeten bevestigen.
Ik heb het idee dat nog niet alle icann registrars dit doen? Enom waar wij zitten in ieder geval wel.
Nou, wij zitten ook bij Enom. Er staan nu vier domeinnamen welke gisteren en vandaag 'offline' zouden moeten gaan omdat verificatie mail nog niet bevestigd is. Echter zijn domeinnamen gewoon nog online.
Ook onze andere domein partner geeft niet thuis op vragen m.b.t. deze ICANN regels.
Al met al heb ik het gevoel dat registries ook hiermee in hun maag zitten hoor :S
dennis0162
27/01/14, 16:36
Ik heb vorige week een paar klanten gebeld vlak voor de Verification Deadline gebeld om te voorkomen dat het domein offline gaat.
Maar dat lijkt dus niet te gebeuren?
Als ze dan toch zoiets willen dan kunnen ze beter een verificatie mail sturen voordat ze het domeinnaam actief maken.
Een soort tussen status "Pending Verification", als het dan bevestigd is binnen x dagen dan het domeinnaam actief maken in de DNS.
Bij Enom gaan ze volgens eigen zeggen ook suspenden als je het contact aanpast en het wordt niet bevestigd.
Vorige week ook een typo gemaakt in het e-mailadres van de klant, dan kan je bij Enom het contact niet nog een keer aanpassen omdat het niet bevestigd is.
Ticket ingeschoten bij Enom, duurde ook een paar dagen voordat ze dat opgelost hadden.
Wij hadden ook zoiets :(
E-mail contact aangepast bij een handle / domein omdat oude e-mail niet meer bestond.
Stuurt Enom doodleuk verificatie e-mail naar _oude_ e-mail adres. Het heeft mij ook enkele dagen (en nachten, want ze reageren alleen 's avond / nacht Nederlandse tijd) om het voor elkaar te krijgen :(
Maar wat ik op dit moment kan concluderen is dat Enom dus het 'verlopen' verificatie e-mail / domeinen _NIET_ offline zet.
En wij hebben eerste 'slachtoffers' :)
Viertal domeinen zijn vannacht door Enom offline gehaald.
Zie bijgevoegde screenshot voor wat bezoekers nu krijgen te zien.
Het is nu wachten totdat klant zicht (wellicht boos) meldt dat zijn website niet meer werkt :(
11382
dennis0162
28/01/14, 10:43
Ze worden dus wel offline gehaald door Enom.
De pagina zelf ziet er op zich netjes uit.
Van bijvoorbeeld MijnDomeinReseller heb ik nog niks gehoord over verificatie van domeinnamen.
Bij RRPproxy hebben we ook nog een oud account en ook daar niks van gehoord.
Voor de goede orde, nadat klant dus bevestigd heeft, krijgen we volgende te zien:
11383
Toch vind ik heel erg dat ze 'zomaar' domeinnaam 2-3 dagen offline mogen houden :(
Ik begrijp wel dat klant / eigenaar ook enige verplichtingen heeft, echter dit kon ook vele malen beter opgelost worden. Door bijvoorbeeld voor nieuwe registraties domeinnaam pas te activeren eenmaal e-mail verificatie gedaan is.
Ze worden dus wel offline gehaald door Enom.
De pagina zelf ziet er op zich netjes uit.
Van bijvoorbeeld MijnDomeinReseller heb ik nog niks gehoord over verificatie van domeinnamen.
Bij RRPproxy hebben we ook nog een oud account en ook daar niks van gehoord.
Wij hebben van RRPPRoxy een uitgebreide mailing ontvangen hierover.
Sommige klanten van me zien ook het volgende en raken helemaal in paniek.
11392
Tja dat was te verwachten met dit soort stompzinnige regels. Wat een verschikkelijke organisatie is het toch.
Echt wel dat de huidige hosters/registrars de schuld krijgen hiervan.
Ik zag dat frankske van OpenMinds het ook al op de website had geplaatst. Denk dat we dat allemaal moeten doen om schade te beperken.
http://www.openminds.be/nl/blog/detail/striktere-controle-voor-domeinnaamhouders
We hebben onze klanten jarenlang verteld dat mailtjes over het vervallen of verlengen van hun domein (vooral in een buitenlandse taal) SPAM is en dat ze dat ongelezen de prullenbak in moeten gooien. Ik word er erg verdrietig van. Niet goed over nagedacht allemaal....
Wij hebben binnen onze klanten pagina prominent na het inloggen een behoorlijke lap tekst geschreven over deze nieuwe ICANN regels.
Tot zover levert het met name 'paniek' vragen van de klanten welke .nl domeintje geregistreerd hebben :( En uiteraard, uit onwetendheid herleiden klanten allerlei problemen daarnaartoe (bv website werkt niet meer correct, mail komt niet eraan, DB error - je kan het niet zo gek verzinnen).
In iedere geval hebben wij hier behoorlijk extra werk aan. Nog erger is dat wij met twee verschillende partijen werken, dus ook verschillende e-mail welke de deur uitgaan en verschillende procedures om alles weer te herstellen.
En nog iets - indien je resellers hebt, dan kan je uitgaande mails niet echt aanpassen (whitelable). Dus het ziet, ruikt en lijkt op het spam - dan zal het ook wel spam zijn (denken klanten).
Ik zie dat OpenMinds wel een hele nette mail in elkaar gezet heeft, maar dat luxe hebben wij dus niet.
Daniel Oxxa.com
11/02/14, 15:03
En een leuke verassing die er aankomt is :
the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A)
calling or sending an SMS to the Registered Name Holder's telephone number providing a unique code that
must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder's
telephone number and requiring the Registered Name Holder to provide a unique code that was sent to
the Registered Name Holder via web, email or postal mail.
LEUKER KUNNEN WE HET NIET MAKEN.... MAAR MAKKELIJKER OOK NIET )-;
En een leuke verassing die er aankomt is :
the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A)
calling or sending an SMS to the Registered Name Holder's telephone number providing a unique code that
must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder's
telephone number and requiring the Registered Name Holder to provide a unique code that was sent to
the Registered Name Holder via web, email or postal mail.
Een registrar mag kiezen of hij per e-mail of telefoon/SMS verifieert.
Het is dus OF en niet EN
Verify:
the email address of the Registered Name Holder (and, if different, the Account Holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or
the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A) calling or sending an SMS to the Registered Name Holder's telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder's telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail.
In het kader van we hebben toch niets beters te doen... Waardeloos, wij bellen klanten die offline dreigen te gaan al na om dit te voorkomen.
En nog iets - indien je resellers hebt, dan kan je uitgaande mails niet echt aanpassen (whitelable). Dus het ziet, ruikt en lijkt op het spam - dan zal het ook wel spam zijn (denken klanten).
Ik zie dat OpenMinds wel een hele nette mail in elkaar gezet heeft, maar dat luxe hebben wij dus niet.
Dat is precies het probleem waar wij mee zitten. Eigenlijk wil je een iets aangepaste mail kunnen sturen afhankelijk van de domeinnaam, zo kun je dan de taal + genoemde namen aanpassen naar wat voor die naam gewenst is. Helaas heb ik nog geen partijen gezien waar dat mogelijk is, wel heb ik deze vraag richting onze leverancier gesteld en hopelijk hebben we hier op korte termijn een oplossing voor.
dennis0162
12/02/14, 01:24
Omdat ik er een beetje "moe" van wordt om er steeds achteraan te mailen heb ik een scriptje gemaakt wat dit automatisch doet.
Het haalt de domeinnamen en de suspend datums op via de Enom API en stuurt de klant een Nederlandstalige e-mail dat de contactgegevens nog bevestigd moeten worden.
Elke 3 dagen wordt de mail automatisch verstuurd, de dagen kan je zelf instellen in de array op regel 25.
De tekst van de mail moet ik morgen nog even nalezen, maar deze kan je naar eigen wens aanpassen.
Het script wat je 1x per dag moet laten lopen via een cronjob.
Let op dat je IP-adres op de whitelist moet staan bij ENOM.
Ik heb nog een ticket uit staan bij ENOM of je ook de bevestigings mail opnieuw kan laten verzenden via hun API.
Daarover wacht ik nog op antwoord van ENOM en zal indien het mogelijk is daarvoor ook even een scriptje maken.
Ik hoop dat iemand er wat aan heeft :-)
En nu slapen (headbang)
<?php
//
// ENOM remember customers to confirm their e-mailaddress
//
// Dennis op de Weegh - Bitency
// Questions? d.opdeweegh@bitency.nl
//
// Use At Your Own Risk!
//
// Your IP-address must be whitelisted for the ENOM API.
//
// Set this script as cronjob once a day
//
// SETTINGS
$enom_username = ""; // ENOM USERNAME
$enom_password = ""; // ENOM PASSWORD
$from_name = "Companyname"; // FROM COMPANYNAME
$from_mail = "mail@address.nl"; // FROM MAILADDRESS
$cc = TRUE; // MAIL CC TRUE or FALSE
$cc_address = "mail@address.nl"; // CC MAILADDRESS
$sendDAYS = array(1, 2, 3, 6, 9, 12, 14); // SEND MAILS X DAYS BEFORE SUSPENSION DATE
$subject = "Bevestig uw e-mailadres voor domeinnaam {domain}"; // SUBJECT MAIL
// MESSAGE
$message = '<font face="Arial" size="2">';
$message .= 'Geachte heer/mevrouw, <br /><br />
Naar aanleiding van een nieuwe registratie van een domeinnaam of een aanpassing aan een bestaande domeinnaam, dienen wij u te vragen om uw e-mailadres te bevestigen. <br /><br />
U heeft hiervoor onlangs een Engelstalige e-mail ontvangen op het e-mailadres {newemailaddress} met daarin een link om het e-mailadres te bevestigen.
Echter is het e-mailadres tot op heden nog niet bevestigd. Het onderwerp van deze mail is "IMMEDIATE VERIFICATION required for {domain}". <br /><br />
<b>U heeft de tijd tot {suspdate} om het e-mailadres te bevestigen. Anders zal het domeinnaam door ICANN* worden geblokkeerd. </b> <br />
* ICANN is de beheerder van alle generieke domeinnamen .com, .org, .info etc. <br /><br />
Indien u deze mail niet heeft gekregen kunt u contact opnemen met onze helpdesk.
Wij zullen u dan een nieuwe e-mail sturen met een bevestigings link. <br /><br />
Mocht u vragen hebben dan kunt u op deze e-mail reageren. <br /><br />
Met vriendelijke groet,<br /><br />
Companyname<br /><br />
';
$message .= '</font>';
// END SETTINGS
$headers = "From: " . $from_name . " < ".$from_mail." >\r\n";
if ($cc) { $headers .= "CC: ".$cc_address."\r\n"; }
$headers .= "MIME-Version: 1.0\r\n";
$headers .= "Content-Type: text/html; charset=ISO-8859-1\r\n";
// ENOM API XML TO ARRAY
$enom_api = @file_get_contents('https://reseller.enom.com/interface.asp?command=RPT_GetReport&uid='.$enom_username.'&pw='.$enom_password.'&ReportType=31&Download=FALSE&ResponseType=xml');
$xml = new SimpleXMLElement($enom_api);
$nasty = "report31-single";
// LOOP ARRAY
foreach ($xml->rpt->results->rptrawxml->{$nasty} as $value) {
// Convert time
$time = strtotime($value['suspensiondate']);
$now = time();
$datediff = $time-$now;
$daysforSuspend = floor($datediff/(60*60*24));
// values in mail/subject
$subject = str_replace("{domain}", $value['domainname'], $subject);
$message = str_replace("{domain}", $value['domainname'], $message);
$message = str_replace("{suspdate}", date('d-m-Y', $time), $message);
$message = str_replace("{newemailaddress}", $value['newemailaddress'], $message);
// IF DAYS matching send mail to cust.
if (in_array($daysforSuspend, $sendDAYS)) {
// SEND MAIL
mail($value['newemailaddress'], $subject, $message, $headers);
}
}
?>
Pastebin: http://pastebin.com/S0N6gAwK
Dennis, ik snap je idee achter deze script. Je bent wel ervan bewust dat registries ook in totaal 5 e-mails verzenden (om de 3 dagen, 15 dagen lang)?
Klant krijgt dan in totaal 10 e-mails per domeinnaam. Een beetje overkill, maar nogmaals heb ik wel begrip voor want wij worden ook langzamerhand moe van allerlei vragen.
En dan ook blijft het 'uitdaging' m.b.t. domeinnamen van de resellers.
Mark17, bij een van onze leveranciers kunnen wij helemaal niks aanpassen aan de e-mail template. Bij eNom kan dat wel, maar er is ook geen onderscheid tussen 'onze' domein en domeinnaam van onze reseller. Maar stel dat registry wel twee aparte templates zou hebben. Hoe zou jij dan onderscheid maken welke geregistreerde / verhuisde domein van jullie zelf is - en welke van een van de resellers?
dennis0162
12/02/14, 12:47
De meeste klanten deleten de mail omdat ze denken dat het SPAM is.
Ik denk dat er een aantal goede domeinnamen verloren zullen gaan aan dropcatchers die dit juist wel een goede zaak vinden.
Domenico, volgens mij zie jij het verkeerd. Domeinnaam komt niet vrij voor de registratie. Het registratie status blijf behouden alleen wordt domeinnaam technisch uit name servers los gekoppeld. Dus kans dat iemand domeinnaam kaapt bestaat simpelweg niet ;-)
Domenico, volgens mij zie jij het verkeerd. Domeinnaam komt niet vrij voor de registratie. Het registratie status blijf behouden alleen wordt domeinnaam technisch uit name servers los gekoppeld. Dus kans dat iemand domeinnaam kaapt bestaat simpelweg niet ;-)
Ja had ik inmiddels al begrepen. :)
En dan ook blijft het 'uitdaging' m.b.t. domeinnamen van de resellers.
Mark17, bij een van onze leveranciers kunnen wij helemaal niks aanpassen aan de e-mail template. Bij eNom kan dat wel, maar er is ook geen onderscheid tussen 'onze' domein en domeinnaam van onze reseller. Maar stel dat registry wel twee aparte templates zou hebben. Hoe zou jij dan onderscheid maken welke geregistreerde / verhuisde domein van jullie zelf is - en welke van een van de resellers?
Het liefste zou ik het standaard bij elke domeinnaam meegeven. Via bv een EPP extensie zou dit perfect mogelijk moeten zijn. Van 1 partij kreeg ik al de optie om er 2 accounts te nemen, dit kan natuurlijk ook (dit is echter technisch een stukje lastiger te regelen aan onze kant en schaalt minder goed aangezien dan ook per reseller daar weer een account nodig is).
dennis0162
12/02/14, 14:32
Mark17
Waar ergens kan je die mails bij Enom aanpassen?
Enom zelf is zo traag met het beantwoorden van tickets.
Mark17
Waar ergens kan je die mails bij Enom aanpassen?
Enom zelf is zo traag met het beantwoorden van tickets.
Geen idee, wij zijn al enige tijd bezig alles bij Enom weg te halen. Echter door een overname duurt dit langer dan eerder gehoopt. Tegen eind dit jaar moet alles er weg zijn (van wat er nu nog staat).
dennis0162
12/02/14, 21:08
Bij Enom is het helaas niet mogelijk om de mails aan te passen:
Hello,
Thank you for contacting Technical Support. I'll be happy to assist you.
Unfortunately there is no way to customize the emails but you can use the command RAA_ResendNotifcation to resend the verification email.
dennis0162
12/02/14, 22:07
Met onderstaande code kan je de mail eventueel opnieuw laten verzenden:
Zelf laten we het even bij het Nederlandstalige mailtje wat verzonden wordt naar de klant.
<?php
// ENOM resend verification mail
//
// Dennis op de Weegh - Bitency
// Use At Your Own Risk!
// Questions: d.opdeweegh@bitency.nl
//
// file.php?domainname=domain.com
// BEGIN SETTINGS
$enom_username = "";
$enom_password = "";
// valid domain?
if (!preg_match('^(?:[a-zA-Z0-9]+(?:\-*[a-zA-Z0-9])*\.)+[a-zA-Z]{2,6}$^', $_GET['domainname'])) {
echo "Domeinnaam niet correct.";
die();
}
// ENOM API XML TO ARRAY
$enom_api = @file_get_contents('https://reseller.enom.com/interface.asp?command=RAA_ResendNotification&uid='.$enom_username.'&pw='.$enom_password.'&domainname='.$_GET['domainname'].'&ResponseType=xml');
$xml = new SimpleXMLElement($enom_api);
// success?
if ($xml->Success) {
echo "De e-mail is zojuist opnieuw verzonden naar uw e-mailadres.";
} else {
echo "De e-mail kan helaas niet opnieuw verzonden worden, neem contact met de helpdesk.";
}
?>
dennis0162
29/09/15, 14:12
Topic kick
Hoe gaat dit bij jullie? Bij ons denken sommige klanten dat het spam is en ze niet op de link moeten klikken in de mail :-)
Wat ik bijvoorbeeld ook raar vindt is dat je bij Enom en Openprovider wel de klant de contacten moeten bevestigen.
Maar bij MijnDomeinReseller en ODR krijgt de klant daar nooit een mail voor om dit te doen bij een nieuwe registratie of wijziging.
Weet iemand hoe dat zit? Ligt er aan hoe je de regels van ICANN interpreteert?
Hoe gaat dit bij jullie? Bij ons denken sommige klanten dat het spam is en ze niet op de link moeten klikken in de mail :-)
Zeg maar gerust de meerderheid i.p.v. sommige
Het is jammer dat de inhoud van het bericht niet aangepast kan worden, want het lijkt ook best op spam.
Wat ik bijvoorbeeld ook raar vindt is dat je bij Enom en Openprovider wel de klant de contacten moeten bevestigen.
Maar bij MijnDomeinReseller en ODR krijgt de klant daar nooit een mail voor om dit te doen bij een nieuwe registratie of wijziging.
Weet iemand hoe dat zit? Ligt er aan hoe je de regels van ICANN interpreteert?
Denk niet dat er genoeg ruimte in de regels (https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy) zit om de e-mail (of SMS) in zijn geheel niet te versturen.
Wel is er enige ruimte om het domein niet meteen uit de lucht te halen, als er vervolgens niet geklikt wordt. Een registrar heeft ook de mogelijkheid om de gegevens handmatig te controleren (en er staat nergens hoe grondig dat moet gebeuren).
if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information.
dennis0162
29/09/15, 16:17
Bij Openprovider kan je de mails wel aanpassen, maar toch denken de meeste klanten dat het spam is.
Ik snap wel dat ze graag de WHOIS up to date willen hebben maar het is een erg vervelend als domeinnamen daardoor geblokkeerd worden.
Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.
Bij Keysystems kan de mail niet aangepast worden maar hebben wij gelukkig een iets betere vertaling van de Nederlandse versie mogen aanleveren die zij hebben opgenomen in het systeem. Helaas worden zaken als datum dan toch nog in Engelse notatie vermeld met als resultaat dat de mail er alsnog onbetrouwbaar uit ziet. Zelfs een eigen stukje erbij dat deze mails namens ons verzonden worden en bij twijfel contact met ons opgenomen moet worden kan het wantrouwen niet weg nemen. Resulteert dus regelmatig in dat we klanten alsnog achterna moeten mailen.
Bij Keysystems kun je ervoor kiezen de validatie zelf uit te voeren, je moet dan bewijslast kunnen aanleveren over de bevestiging als ze daarom vragen, op straffe van 10.000 Euro boete als je dat niet kan...
Bij Keysystems kun je ervoor kiezen de validatie zelf uit te voeren, je moet dan bewijslast kunnen aanleveren over de bevestiging als ze daarom vragen, op straffe van 10.000 Euro boete als je dat niet kan...
Lees dat je dan nog steeds opnieuw een e-mail moet sturen NADAT er een domein geregistreerd is, waarbij je verplicht wordt om de door KS opgegeven verificatie code te gebruiken:
When verification is required under the RAA, KS will provide to RSP an RRPproxy
verification event containing a unique trigger code and the email address of the RNH.
Dat wil ik nu juist niet, want dan heb je nog steeds het probleem dat een klant het mailtje over het hoofd ziet en het domein na een paar weken op zwart gaat, terwijl de klant het idee had dat alles netjes afgerond was.
Ons systeem verifieert het e-mail adres van de klant al op het moment dat deze zich als nieuwe klant aanmeld, VOOR de registratie, en begrijp niet waarom dat niet voldoende is...
Lees dat je dan nog steeds opnieuw een e-mail moet sturen NADAT er een domein geregistreerd is, waarbij je verplicht wordt om de door KS opgegeven verificatie code te gebruiken:
Dat wil ik nu juist niet, want dan heb je nog steeds het probleem dat een klant het mailtje over het hoofd ziet en het domein na een paar weken op zwart gaat, terwijl de klant het idee had dat alles netjes afgerond was.
Ons systeem verifieert het e-mail adres van de klant al op het moment dat deze zich als nieuwe klant aanmeld, VOOR de registratie, en begrijp niet waarom dat niet voldoende is...
Ik interpreteerde dat toch anders. Als je kiest om het zelf te doen, doet rrpproxy niets en moet je het helemaal zelf doen (weet niet of daar nog een voorgeschreven vorm aan zit). Pas zodra rrpproxy zich moet verantwoorden komen ze naar jou, en moet jij aantonen dat er geverifieerd is.
pannenkoek
29/09/15, 21:26
Bij realtime register krijgen klanten eerst een mailtje die ze moeten accepteren daarna zal het domein worden verwerkt.
Dit vind ik zelf erg fijn zodat je achteraf niet het gezeik krijgt dat het domein offline is.