[DBTech] DragonByte Mail

[DBTech] DragonByte Mail [Paid] 5.1.0b2

No permission to buy (€14.95)
About the AWS SES automated bounce handler, does it support if I have multiple XF domains under one Amazon SES account?
You’d set up the endpoint as explained in the FAQ, I’m reasonably sure you set the complaint and bounce topics per domain.
 
  • Like
Reactions: rdn
Are there any controls on which email addresses to validate, when and how often?
For big boards the costs can rack up quickly to hundreds of euros per run and I don't want verification credits to go to waste.
 
Are there any controls on which email addresses to validate, when and how often?
For big boards the costs can rack up quickly to hundreds of euros per run and I don't want verification credits to go to waste.
Verification happens once every six months, which is the recommended revalidation time.
 
For all accounts?
We have hundreds of thousands of accounts. Depending upon the provider the cost of validating each account againand again would be between €500-€1000 every 6 months. That would not be a realistic expense.
Accounts that we are not going to email or accounts that have recently been emailed do not need to be validated. Validating those accounts would be costs that can be avoided .

Some controls would be very welcome.
 
This is implemented:
 
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:

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.
 
Last edited:
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:

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:
  • Unknown
  • Risky
  • Fail
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... 🤔
 
Thanks for explaining!
What is the cron command?

If I understand correctly then the software does not validate emails that have 'Awaiting email confirmation' status.
This would be an interesting feature to have, because most likely there will be users that have never confirmed their email, but have valid email addresses. I send out mass emails to these members to see if they will confirm their email or if they are running into any issues. Especially since my email service has been suspended for some time by SES (due to XF1 not meeting requirements and not having site style & logo in transactional emails)
it would be nice to validate those accounts as well, before sending email to them. I don't want to risk getting suspended again, but I do need to email those users.

Please consider to add a setting for this.
 
That doesnt explain enough to work with it. None of the options make sense to me, as its not clear why or when I would need any of the options.
So we have:
dbtech-mail:validate-emails [options] [--] <batch>
How do I set this to 500?
I see that -h is for help, but it doesnt explain where to put the -h.
 
That doesnt explain enough to work with it. None of the options make sense to me, as its not clear why or when I would need any of the options.
So we have:
dbtech-mail:validate-emails [options] [--] <batch>
How do I set this to 500?
I see that -h is for help, but it doesnt explain where to put the -h.
What? I'm so confused... php cmd.php dbtech-mail:validate-emails 500 sets the batch size to 500.
 
Back
Top Bottom