[DBTech] DragonByte Mail [Paid] 5.1.1

[Alpha1]

Mhm. Now it does not take action on disposable emails. Example:
{"can_connect_smtp":null,"domain":"embarqmail.com","email":"xxx@embarqmail.com","has_inbox_full":null,"is_catch_all":null,"is_deliverable":null,"is_disabled":null,"is_disposable":true,"is_free_email":true,"is_role_account":false,"is_safe_to_send":false,"is_spamtrap":false,"is_valid_syntax":true,"mx_accepts_mail":true,"mx_records":["mx.centurylink.net"],"overall_score":30,"status":"disposable","username":"xxx","verification_mode":"power"}

Clearly this should be a hard bounce because its a disposable email that cannot be delivered to. Its not safe to send now and will never be safe to send. I find quite a few with dodgy disposable mail domains in the log. Quite a few are of the bugmenot.com type. (i.e. people share the login credentials so anyone can log into the forum account)

 

[DragonByte Tech]

Clearly this should be a hard bounce because its a disposable email that cannot be delivered to. Its not safe to send now and will never be safe to send. I find quite a few with dodgy disposable mail domains in the log. Quite a few are of the bugmenot.com type. (i.e. people share the login credentials so anyone can log into the forum account)

I'm not sure I agree with this. Are you 100% sure that absolutely no free email providers will be flagged as disposable via this validator?

I understand the difference between a publicly accessible disposable email and a free email like Google Mail, but I'm not confident they make that distinction.

I'd rather make a change to check is_deliverable.

 

[DragonByte Tech]

Btw @Alpha1 in the next version I’ll also make a change that updates validation date when the user gets sent an email. It has to be sent by using setUser() which is most emails sent by XF and my addons.

An example of email not using that code is the email test feature.

That should reduce validation costs going forward I’ll see if I can reasonably add the criteria before releasing but I can’t promise that one.

 

[Alpha1]

This addon is getting better and better.

I'm currently doing tests in 30k and 50k batches. I may be wrong but it seems to me that some of the same accounts that have UNKNOWN result are getting checked again with every batch and therefore the percentage of UNKNOWN results gets higher per batch. Some of the results seem familiar. Is that a correct assumption?

 

[DragonByte Tech]

This addon is getting better and better.

I'm currently doing tests in 30k and 50k batches. I may be wrong but it seems to me that some of the same accounts that have UNKNOWN result are getting checked again with every batch and therefore the percentage of UNKNOWN results gets higher per batch. Some of the results seem familiar. Is that a correct assumption?

Are there any entries in the XenForo server error log? Also, check the raw_message column in xf_dbtech_mail_validation_log. This is the column I'm referring to when I say "logged" in the rest of this post.

For Reoon specifically, there are three possible reasons why someone would be logged as Unknown:

1. There was a problem reaching Reoon's server, either from an outgoing firewall rule or an aborted connection (or whatever other reasons Guzzle might throw an exception). In this case, the full exception message will be logged.

2. The status or email fields are not found in the result. An UnexpectedResultException is logged in the XF server error log, and the raw response is logged.

3. The status field is not one of the following:

• safe
• role_account
• disposable
• catch_all
• spamtrap
• inbox_full
• invalid
• disabled

The raw response is logged.

---

All of that being said, it does not stop the validation date from updating. The date is updated before the call to the validator's server is made, so even if it was a server error on their part, it would not be revalidated before the 6 month period is up.