[DBTech] DragonByte Mail [Paid] 4.0.1

[DragonByte Tech]

Yeah, V4 release (non-beta).

After your suggestion I tried removing the directory, and copying files. Still the same error when I try to delete a user.

Next I tried removing the directory, copying files and uninstalling. It gave the error message during uninstall, but otherwise seemed to uninstall. Then I recopied the new files again, and doing a fresh install. Same result, any attempt to delete a user results in the error.

I did a grep on the contents of the zip file to make sure I covered the contents of the XML as well:

 find . -type f -exec grep -H "DBTech_Mail_Cache" {} \;
./upload/library/DBTech/Mail/XenForo/DataWriter/User.php:               DBTech_Mail_Cache::getInstance()->build('mailinglist');

The class DBTech_Mail_Cache is only referenced there, and the class does not appear to exist anywhere in the source.

Thanks!

Try replacing that line with \DBTech\Mail\Application\App::cache()->build('mailinglist'); and let me know if that works


Fillip

 

[MySiteGuy]

That works. Thank you as always for the great service. Which reminds me, it's time to give positive reviews of the various DB Tech products I use.

 

[MySiteGuy]

Question concerning GDPR, what does this addon do so far as compliance measures?

Thanks!

 

[DragonByte Tech]

Question concerning GDPR, what does this addon do so far as compliance measures?

Thanks!

There are no measures needed for this addon. If you choose to use an external SMTP server to send your emails, then it would be up to you to declare this in your Privacy Policy, if your country's legislation requires this.

In terms of consent, this addon respects the global "Receive site email" setting in addition to the user's own subscription flag to individual messages.

In regards to unsubscriptions, much like XF2's built-in mailing list system, this addon supports one-click unsubscribe that does not require the user to be logged in.


Fillip

 

[MySiteGuy]

Thank you.

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Mail with a new update entry:

4.0.1

Update highlights

This version fixes a few issues reported by our customers.


Complete Change Log

XenForo 1.5.x
Fix: FIxed a server error when deleting users

XenForo 2.0.x
Fix: Fixed an issue where the wrong phrase variable was used in the "Inactive User Reminder" email

Read the rest of this update entry...

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Mail with a new update entry:

Resource Guidelines Update

What is happening?
On the 11th of July 2018, XenForo published their Resource Guidelines aimed at ensuring performance & stability of XenForo modifications. At the moment, this product does not meet these standards, due to the fact that this product has been engineered to allow the core code to run on both XenForo 1 and XenForo 2.

As a result, I am beginning work on re-engineering this product to become a "native"...

Read the rest of this update entry...

 

[MySiteGuy]

Strange bug. If I create a mailing list, then go to it's permissions, select the user groups which can subscribe, and then save, when I go back into the mailing list and go to permissions none of the changes I make show up. Everything stays "Default". This is version 4.0.1, XF 1.5

 

[DragonByte Tech]

Strange bug. If I create a mailing list, then go to it's permissions, select the user groups which can subscribe, and then save, when I go back into the mailing list and go to permissions none of the changes I make show up. Everything stays "Default". This is version 4.0.1, XF 1.5

Check the max_input_vars flag in your php.ini file, make sure it's set to 100000 or higher.


Fillip

 

[MySiteGuy]

It was set pretty high, 1000, never had any issues with large numbers of permissions (some XF admin screens are about 5x longer). But I changed it as suggested to 100000, restarted php-fpm and the problem persists. Nginx and php also have very high max post sizes (140mb) since I allow video uploads to the server).

 

[DragonByte Tech]

But I changed it as suggested to 100000, restarted php-fpm and the problem persists.

Can you just double-check admin.php?tools/phpinfo in the AdminCP to see if it did take effect? DBTech runs on php-fpm too and sometimes changes can be a bit finicky so I just want to make sure it actually applied.


Fillip

 

[MySiteGuy]

Its good:
max_input_vars 100000 100000

 

[snoopy5]

Hi,

in the description of this addon, it is written under "Sending emails":

Uses XenForo's Mail Queue system to avoid overloading servers / avoid "maximum mails per hour" server restrictions

How exactly does that work? I need to set this up to send maximum 1000 emails every 10 Minutes.

 

[DragonByte Tech]

How exactly does that work? I need to set this up to send maximum 1000 emails every 10 Minutes.

It means that if you have installed a 3rd party addon that modifies XenForo's mail queue to comply with restrictions like that, or XF has/gains the ability to do that, then that will work with this mod.

By default, DB Mail does not (and will not) interfere with how XF sends mail.


Fillip

 

[snoopy5]

a 3rd party addon that modifies XenForo's mail queue to comply with restrictions like that

Do you know by accident of any 3rd party addon which does that?

 

[DragonByte Tech]

Do you know by accident of any 3rd party addon which does that?

I do not, sorry. I would never touch a web host which imposes such restrictions, so I've had no reason to look for it for personal use. I've not heard anyone mention such a mod in a thread like this either.


Fillip

 

[snoopy5]

I thought about moving to another server too, but at the end of the day, it does not make a difference if you think about the reason behind these restrictions.

Almost all email providers put your domain on a blacklist if they receive too many mails within an hour from your domainame.

So I have no benefit to be able to send out tons of emails per hour, but none is getting through their firewall, because I sent too many within an hour. I will not get any feedback from them. I will only get to know it by accident if my users are telling me that they do not get anymore emails from me.

So whether I like it or not and whether my webhoster allows it or not does not matter anymore. I need to be able to restrict the amount of emails per hour / minute and even better make sure, that the same domainname like gmail.com does not get 200 emails within 2 minutes fom my forum/domain or server.

In phplist I can change the settings to determine how many emails the same email provider gets within a minute etc., but this is an independent (free) software for managing mailings lists. It is not an addon for XF.

 

[DragonByte Tech]

Almost all email providers put your domain on a blacklist if they receive too many mails within an hour from your domainame.

Do you have a source for that information? This is the first time I'm hearing about it, and we've sent email to our entire customer base (that was signed up) dozens of times in the past (back when our primary focus was a platform with less good ways of notifying users of updates) without having run into that issue.

The only time we were ever on a blacklist was before I learned about SPF and DKIM, but after setting that up there was never another issue.


Fillip

 

[snoopy5]

Do you have a source for that information?

Nothing at the moment in written. I called several different webhosters. Some have restrictions, some not to send out mass emails. But all of them told me the same. Maybe they do not want to have new clients, which send out a lot of emails?

 

[DragonByte Tech]

Maybe they do not want to have new clients, which send out a lot of emails?

If you are on shared or (to a lesser extent) VPS hosting, then this is absolutely the reason. If you buy shared hosting, then you are sharing an IP address with potentially a dozen other websites, depending on the size of the package they are selling.

Email providers like Gmail and Outlook only care about the mail server IP, so they don't care if spam is coming from your domain or another domain on the same server, it's the IP address of your server that's going to go on the blacklist.

Saying "email providers blacklist senders who send a lot of email" makes absolutely no sense if you think about it, because if that was true then literally no forum on the entire internet could send a forum newsletter unless they paid for a 3rd party service. It does however make perfect sense if you think about it from a business standpoint. The hosts you're calling will have thought; "what can we tell this person that justifies our restrictions that they are unlikely to question?"
You're not going to ask the hosts for a source for their claim over the phone, as they could just say "well we can't read out a URL to you over the phone, can we?" and then you'd be stuck. They know you're forced to take them at their word.

If they had said "we restrict emails per hour to stop the damage any spammers can do, so that your email delivery isn't affected" then you could counter with "but I'm not a spammer, can't you just lift the restrictions for me?"

That's not to say that they're inherently wrong for restricting the emails per hour, as shared hosts do have a responsibility to protect the other customers on their account. My point is, however, that if you are serious enough about your forum that you want to send a newsletter, then you may wish to pay for the premium of a VPS without such restrictions.

All of that being said, I can see a world where they may be technically correct, for instance if every site on every server was sending out a newsletter at the same time and a large amount of those newsletters were being flagged as spam, then you could sort-of-in-a-roundabout-way say that it was the volume of the emails that caused that provider to blacklist the server.

Personally though, I would never accept such restrictions and I would look into either sending my email via Amazon SES (which we @ DBTech do, in spite of having a dedicated server) or buying a better web hosting package.


Fillip