Enhancement Request: Validate Emails entered on Squeeze forms

[StarCircleAcademy]

I’m seeing a rash of people trying to get my squeeze form content by entering rubbish in the email field, despite my clear instructions that say “If your email address is incorrect, you won’t get the content”. I will probably move this particular item to offer it as a freebie for signing up on my email list, but I was thinking another solution might help:

Have the field do a dns lookup on the domain name portion. Then entries like “qilvkr.com” would fail. This could be done on the client side in Javascript [http://www.fileformat.info/tool/rest/dns-json.htm]

Or in the backend in PHP (or both).

I imagine this setting could be a store option, two actually: do client side email validation (yes/no), do server side email validation (yes/no).

One of the reasons I’d like to have this, in addition to cutting down on bogus entries, is that allowing rubbish in the email field pollutes my autoresponder list.

[wzp]

Please submit your request to the eStore feature request (wish list).

http://www.tipsandtricks-hq.com/ecommerce/wordpress-estore-wishlist-feature-suggestions-148

[admin]

Just validating a domain name still doesn’t prove that it is going to be a correct email address. For example someone can still enter the following:

[xyz123@yahoo.com]

If you are finding that these are bots, then add the captcha to the squeeze form. eStore already has a feature to add captcha to the squeeze form.

[StarCircleAcademy]

Hmmh. Why doesn’t the “Wish List” forum appear in the list of Forums? And where is the description of what has been requested? I see, for example “Black list email”.

I realize that checking the domain doesn’t verify accuracy, but an invalid domain will not be deliverable. My problem is not currently with robots… it’s people who mistype things, sometimes intentionally (to see if they can get a download), sometimes accidentally.

I’ll be glad to write the code to do the domain validation and submit it for your approval as I have done in the past. I imagine it would consist of a new Store setting: “Validate email -> On Client | On Server | On Client and Server”

[admin]

estore uses the is_email() check that comes from WordPress core. WordPress deliberately remove the dns check from that validation function. Here is some more info for you:

https://core.trac.wordpress.org/changeset/14381

I am not very interested to add a dns checking function (which wordpress considers not reliable) to estore core.

I think an addon is the best way to handle this. If you can write me a PHP function that takes an email address and returns with a true of false (after the dns checking) then I will be able to use it to create a small eStore addon.

[StarCircleAcademy]

To follow up on this, it appears one squeeze form has been the target of bots. I was originally thinking that implementing a client side domain check would help, but given that it’s bots, it would have to be server side so there are really only two solutions: remove the squeeze form or add a captcha. Since I find Captcha’s to be a distasteful nuisance, I’ve removed all of my squeeze forms and replaced my free items with $1 items and either an add-to-cart or a buy-now button. I also added text that says “Join my mailing list to get this for free”.

Here are just some of the items entered in one day:

[ybuyzy@echbcs.com]

[xgajbc@cyuppc.com]

[ybiroxrr@ygdeirou.com]

And these are the IP addresses the bogus address are coming from:

5.9.82.107 (Germany)

91.232.96.2 (Germany)

5.9.145.107 (Germany)

61.55.141.10 (China)

5.9.152.10 (Germany)

I might look into plugging in the “Are You A Human” tool instead or Confident Captcha. They are not as painful as CAPTCHA (or reCaptcha).

[wzp]

The reason why WordPress no longer uses checkdnsrr() in the core is that it has become a DDoS attack vector.

[http://stackoverflow.com/questions/13750999/how-reliable-is-checkdnsrr-for-email-domain-validation]

[StarCircleAcademy]

wzp: Yes, I realized the DOS possibility… that why my first thought was to do it on the client side in javascript. But once I discovered it was a robot smacking my forms client side stuff didn’t make sense anymore (though it would solve the problem for a REAL person who mis-enters an email address).

For the squeeze forms, perhaps another validation might be useful: using client side javascript to insert a hidden field into the form submission. The server could then reject the form if the field isn’t present. A stronger implementation would randomize the field name on the server – could be as simple as using the current time in milliseconds. For example, a random HIDDEN field could be sent to the client named “XY_445562” where the number portion is random. The client javascript would then have to create a new hidden field that is differently but predictably named and copy some value into it (like the email address). For example the new field might be “XY_265544” (the digits are reversed). The server would then check that both fields exist when the post is received and reject a request that didn’t meet the test. If the test fails, the user could be presented with a CAPTCHA or similar.

[wzp]

Or, the hidden field could be something like “Phone Number,” or “Confirm Email,” and if the field comes back filled out…

[Author]

Posts