I seem to be encountering two issues:
I have set EmailListVerify API and set the limit to 100 accounts.
Then I ran /admin.php?dbtech-mail/logs/email-validation 2 times. In my EmailListVerify account I see that 50 accounts were validated trough single email verification.
But the log only shows 14 accounts.
I then ran the cron manually.
In the EmailListVerify account I see there are 25 single email verifications done per cron run instead of 100 bulk. In the email verification log of DBT mail not all email verifications are visible.
In total it 125 validations have been done and 34 are visible in the dbt mail log.
Is there anything I need to do here to resolve it?
Updated the feature request:
If I'm understanding it correctly then email validation is done for all accounts, every 6 months. Because this can quickly rack up costs, please consider to implement a few settings to limit which email accounts are validated: Do not validate emails for registered in the past X months. Do not...
www.dragonbyte-tech.com
This feature request would save hundreds of dollars per run. As is the existing credits will be wasted on validating accounts that will never receive email or that we already know are valid.
This is not a bug nor is it a problem. I'll break it down per point:
Email validation is already using the criteria system internally.
The only users who are validated are users who meet the following criteria:
- They have never been validated before, OR it has been more than 6 months (15778458 seconds) since the last time they were validated
- The email field isn't empty (i.e. user generated by admin)
- The user state is
valid
- The user is not banned
Could this be expanded upon? Sure, but it absolutely does
not validate users who will not receive any kind of email.
Email validation log only lists failures, not successes.
If you validate 100 users and 14 accounts show up in the email validation log, that means 86 emails passed validation. Depending on the validator, the validation result (
message_type
in the database) can be one of:
The only particularly pertinent action is "Fail", which will be logged as a hard bounce and will be passed to XenForo's bounce action handler as a hard bounce. Depending on the validator, the other two may contribute to the soft bounce counter or may be ignored, depending on how the API returns data which differs on a service-by-service basis.
Cron jobs run with different rules.
The cron job is hard-coded to run only 25 per run, because (again, depending on the validator) the response timeout can be long and as such it can take a long time to run the cron job if I used 100 emails per run. The CLI allows you to specify a batch size because you are obviously not beholder to browsers remaining connected for X seconds when running a CLI command. You could even validate your whole user base in one go via CLI if you're willing to leave your computer on for the requisite amount of time.
As for the feature request, it's definitely something to take into consideration. It's somewhat complicated by the fact that I do need to have the aforementioned criteria always apply, and there is no clear way to communicate to users that certain criteria are forced.
Furthermore, I don't want to encourage or allow a situation where someone might say "Well I'm only sending mass emails to usergroup X so I only need to validate them", which ignores all of the normal XenForo emails that the user will not receive if their email is bouncing.
For example, let's say you need to send a sitewide notice that your site has been compromised and everyone should reset their passwords. Are you only going to send such a critical email to people who signed up for your newsletter? I would argue that such an important email should also bypass the "Receive emails from administrators" setting.
You would end up with potentially thousands of emails bouncing and being in trouble with Amazon, if you only validated a portion of your user base. Ask me how I know
But, as the bot may or may not have already responded to that ticket with, feature requests do not receive a comment unless necessary. It's still logged. Although I suppose I should copy the above into that ticket...
