I haven't touched this add-on in a while but from what I remember email verification will fail.What happens when you run out of credit? Will users still be able to register or change their email account?
To enable/disable email verification for custom fields.What is the check for custom fields?
That would be bad. The admin would not be aware of it.I haven't touched this add-on in a while but from what I remember email verification will fail.
Please explain what this means. Do you mean that when a user edits a profile field their email is verified? I assume this does not relate to other custom fields like custom thread fields?To enable/disable email verification for custom fields.
Please explain what this means. Do you mean that when a user edits a profile field their email is verified? I assume this does not relate to other custom fields like custom thread fields?
Any word on mass verification of existing accounts?There is none right now. I do plan on adding this soon™.
There is no error code for that.Thats great.
In regards to the API not responding or being out of credit: please add a solution for this. For example a setting or allowing the registration to go through in such case. Or create an error or email notification to the admin. Something that lets the admin know there is an urgent need for action.
Have been busy quite lately so couldn't look into this.Any word on mass verification of existing accounts?
Any word on mass verification of existing accounts?
Is this still on the horizon? I've got about 9K existing accounts that, before sending out an email to them via Amazon SES, I'd like to get them checked and if they're invalid have their account status changes to 'email bounced' (the same as if XF did it with it's own bounce handling).Have been busy quite lately so couldn't look into this.
Changelog
- Fixed: Registration not verifying email as expected
- Fixed: Made compatible with other add-ons that extend
XF/Service/Contact::validateEmail()
- New: Ability to go through all valid users, check their email address and update their state to "Email invalid"
- New: New page to view logs and response given by the Email List Verify
- General code changes and improvements
debounce offers a 25% affiliate fee for the developer.You should use https://debounce.io its 50% cheaper than email list verify
Can it be checked what happens in batch mode also when checking existing addresses? (For anybody else, the option is underCould you please look into the issue that registrations are blocked if the API doesn't respond?
Please add a setting to not block registrations if the API doesn't respond.
Tools -> Rebuild Caches -> Email List Verify: Validate users email address
.I have created an issue for it: https://github.com/ticktackk/EmailListVerifyIntegrationForXF2/issues/1Could you please look into the issue that registrations are blocked if the API doesn't respond?
Please add a setting to not block registrations if the API doesn't respond.
If someone was willing to fund it, sure.Overall DeBounce seems to be way more attractive, especially cheaper. @batpool52! , any chance ?
If the user doesn't have a valid address their user state is changed to "Email invalid (bounced)" (Can it be checked what happens in batch mode also when checking existing addresses? (For anybody else, the option is underTools -> Rebuild Caches -> Email List Verify: Validate users email address
.
email_bounce
).Currently if the response is 'My only other question is what status codes are considered as invalid when it comes back from the Email List API? Using some real-world examples, a "@free.fr" address is coming back on the Email List test check as valid but "Risky". If I ran the task would that person have been left alone or would they have been changed to an invalid state?
ok
', 'ok_for_all
' and 'accept_all
' then the email address will be considered as "valid".Changelog
tckEmailListVerifyIntegration_response.spamtrap
associated to the resultcode "spamtrap". This is from their API docs:Looks like a missing phrase has popped up in the log files.....tckEmailListVerifyIntegration_response.spamtrap
associated to the resultcode "spamtrap".
This could be because once the log is older than 24 hours, that log is considered as "get fresh log we don't trust this". I might need to add a toggle to control the visibility.Does anybody familiar with EmailListVerify know if their "Stats" numbers are delayed? In the XF log I'm showing a higher number of entries than what appears on their web Stats page.
You know how it is with devs and documentation.This is from their API docs:
In this case they're all from today's test run. In the XF log there are 28 entries dated within a minute of each other while on the ELV 'stats' web page they show 20 total. Not necessarily a bad thing if if means they'll ding me for less credits than checks actually done. Poking around it doesn't look like there is a way of seeing the API usage details on their side.This could be because once the log is older than 24 hours, that log is considered as "get fresh log we don't trust this". I might need to add a toggle to control the visibility.
We use essential cookies to make this site work, and optional cookies to enhance your experience.