Why do i need to add them?
The reason why MailBul uses cron jobs is very simple, the tasks that it runs, to send campaigns for example, are tasks that can take a long time to execute and if you run these tasks as a regular web page, then not only we would need to interact with these pages in order to trigger the actions, but also it would mean we need to keep those pages open as long as they execute and that the execution might fail for a dozen of reasons (say script timeout, or memory limit, etc). Using cron jobs, all these actions are handled without our interaction and can run for unlimited time without the need of interaction.

How do i add them?

The bright side is that, control panels like CPanel or Plesk will give you a web interface to add your cron jobs easier.
Youtube has a bunch of videos for CPanel, Plesk , DirectAdmin and others, so there shouldn’t be a problem adding yours no matter what control panel you are using.

The post What Cron Jobs are, why do i need to add them and how? appeared first on MailBul KB.

Let’s look at this:

So we have 10 campaigns at once and 100 subscribers at once.
What does that mean is that when the cron job will run, that is, each minute, it will load from the database 10 campaigns that are ready for sending and sequentially, for each campaign, will load 100 subscribers, send 100 emails for first one, then pick the next campaign and load 100 subscribers and so on till the 10th campaign is done.
Keep in mind that for each email that is processed, there is a certain memory usage which depends on the size of the template used in the campaign, on the number of custom fields for the list used in campaigns and various other factors, like the in memory cached list field definitions and so on.

Now, remember how i said that each minute the cron job runs and picks up campaigns for sending?
If we look at the below settings:

And imagine that at minute 1 the cron job runs and picks up the campaigns and starts sending 1000 emails for first campaign (rest of them still wait for sending).

While the first campaign is still processing, the cron job at minute 2 also runs, and starts sending for the second campaign, that is 1000 more subscribers to process, and we go on till cron job number 10, which processes 1000 subscribers at once. So we end up processing around 10k subscribers at some point because we loaded a high number of subscribers for each campaign and that campaign didn’t finish sending while other campaigns started sending.
Now, this should become very obvious on the number of issues it can create on a slow server(or slow smtp server), that’s why you should be really careful at these settings, it’s not just how much memory usage a single cron run does, but it’s also about the number of the cron jobs that end up running at same time.

Next, if we enable PCNTL sending, say like:

Means that when the cron job runs, it will process 5 campaigns at once.
For each campaign, it will load 5 batches of 1000 subscribers.

Doing a quick math, 5 campaigns * 5 batches of subscribers * 1000 subscribers = 25000 subscribers at once. Now take memory usage into consideration for 25k subscribers at once and take network connections into consideration and also take in consideration when next cron runs and starts doing 25k subscribers at once again if the first cron didn’t finish yet and so on.

Bottom line is that you should really take into consideration all the above.

Don’t set high values if you don’t know what they do.

Since MailBul runs things in batches, it’s always better to run small numbers than huge ones.

The post Understanding email delivery settings and how they impact performance. appeared first on MailBul KB.

<?php
define('MW_PERF_LVL', MW_PERF_LVL_DISABLE_DS_LOG_USAGE | MW_PERF_LVL_DISABLE_CUSTOMER_QUOTA_CHECK | MW_PERF_LVL_DISABLE_DS_QUOTA_CHECK | MW_PERF_LVL_DISABLE_DS_CAN_SEND_TO_DOMAIN_OF_CHECK | MW_PERF_LVL_DISABLE_SUBSCRIBER_BLACKLIST_CHECK);

Then it will disable all the features as described below in the definitions:

'MW_PERF_LVL_DISABLE_DS_LOG_USAGE' => 2, // disable delivery server log usage
'MW_PERF_LVL_DISABLE_CUSTOMER_QUOTA_CHECK' => 4, // disable customer quota check
'MW_PERF_LVL_DISABLE_DS_QUOTA_CHECK' => 8, // disable delivery server quota check
'MW_PERF_LVL_DISABLE_DS_CAN_SEND_TO_DOMAIN_OF_CHECK' => 16, // disable checking if can send to domain of the email address
'MW_PERF_LVL_DISABLE_SUBSCRIBER_BLACKLIST_CHECK' => 32, // disable checking emails against blacklist

You don’t have to disable all, you can only “disable delivery server log usage” and “disable delivery server quota check”:

define('MW_PERF_LVL', MW_PERF_LVL_DISABLE_DS_LOG_USAGE | MW_PERF_LVL_DISABLE_DS_QUOTA_CHECK);

Or any other combination of flags.

Please note that you should disable these only if you don’t care about how many emails a customer sends for example, or if you don’t care about the blacklist checks and all.

The post The performance flags. appeared first on MailBul KB.

1. You have no active delivery server.
2. You have one/more active delivery servers but they are over the hourly quota
3. You have a valid delivery server but you have set some sending quota for the customers and that particular customer reached it.
4. You have a valid delivery server but the customer is in a group that has certain sending quota and he just reached it.
5. You only have delivery servers for campaigns (the Use for flag from the delivery server is set to campaigns).
6. Your customers are set in a group that is not meant to reset the sending quota for a fresh start once it has been reached.

Fixes for the above issues as they are listed :
1. Make sure you add and validate at least one delivery server and it stays active after you modify it(some changes to the delivery server require revalidation).
2. You have no option than to wait till next hour when the hourly quota is fine.
3. Check your Backend -> Settings -> Customers -> Sending settings. Maybe also reset the customer quota.
4. Check the particular group settings, the Sending tab is where you should look at. Maybe also reset the customer quota.
5. Add a delivery server where you set the Use for flag to All.
6. Edit your customer group and in the Sending tab, set the “Action when quota reached” to “Reset the counters for a fresh start”. Please note that you might not want to do this as it means once your customers Hit the quota, it simply gets reseted, which beats the whole purpose of having a quota in the first place.

The post Why do i get this error: email delivery is temporary disabled ? appeared first on MailBul KB.

The reason for why these cron jobs are not running might vary, might be because you haven’t added the cron jobs at all, or because you didn’t properly add them, and by this i mean:

1) the php binary, usually located at /usr/bin/php is not located there on your server.
This can be easily fixed if you have command line access and you run the command

which php

which should return the right path to the php binary. This might be something like /usr/local/bin/php instead of the traditional /usr/bin/php
Also, sometimes, the command line php is compiled with other options than the web binary, therefore if your web version of php is 5.2 this doesn’t mean the CLI version is also 5.2, it can as well be 5.0. You can test this from command line by running

/usr/bin/php -v

which will show you the php version.
If you don’t have command line access. best would be to ask your hosting about this info.

2) the path to the console.php file which triggers the console commands is wrong.
This can happen if you are moving the app from a server to another and you forget to update the cron jobs, but also happens if you don’t follow the last step of the installation and add the cron jobs as instructed there and you add them later.
The path to the console file should be something like: /the/absolute/path/on/your/server/to/apps/console/console.php

Other reasons:
1) You try to run more campaigns than you actually allow from settings, so go to Backend -> Settings -> Cron and put 100 in the campaigns at once field, just as a test to see if it fixes your issue. If it does, lower this number to a lower one, say 20 so that you don’t waste your server resources for nothing.

Note: Some hosting providers, especially on shared hosting, will delay your cron jobs to run at at least 15 minutes instead of, say, one minute. If this happens, then the cron job for sending campaigns for example, will be triggered once at 15 minutes thus you will get a delay while sending your campaigns. Best way would be to not use shared hosting and go with a VPS where you can control everything.

Please also see CRON JOBS list for a list of cron jobs that you have to add on your server.

The post My campaigns don’t send, they’re stuck in “Pending-Sending” status appeared first on MailBul KB.

This area contains a lot of information that tells you exactly how your sending works, if there are errors, and if there are, what type of errors.
Most of the time, you’ll see errors where the remote server doesn’t accept connections from your server anymore, or that i screwed things with an update and i broke some implementation for certain type of delivery server(it happens, we’re all humans), or for any other various reasons, regardless of which, they are all listed in the logs area and you should look at that area often enough to make sure your app works properly.

Same is true for the bounce logs area from Backend > Miscellaneous > Campaigns Bounce Logs.

Bottom line, when in trouble, read the logs, the solution of the problem might as well be listed there

The post Delivery and Bounce logs, why you should monitor these! appeared first on MailBul KB.

Step 1: Login as a customer into your application and go to your lists:

Step 2: Click on your list title or on the Info icon for your list

(see highlighted section on Step 1)

to see the list overview page from which you will click on the Tools box :

Step 3: Click on the Import box:

Step 4: Choose one of the import options depending on the file you need to upload:

That’s it, once you select the file, the import will start and your subscribers will be imported into your list.

Possible issues and fixes:
1) if you get an error that the file type is not allowed, you can go to Backend -> Settings -> Import/Export and disable mime type checking.

2) if the app complains that the filesize is too big, go to Backend -> Settings -> Import/Export and increase the allowed size for uploaded files. If the app still complains afterwards, contact your host to alter your PHP configuration and allow bigger files.

3) if the importing doesn’t start, or it dies while processing, then most likely you have set too many Subscribers to process at once from Backend -> Settings -> Import/Export, so make sure you lower down the number to an acceptable one where the server will be able to process the files.

The post How do i import subscribers appeared first on MailBul KB.

When a bounce server is being used to process bounces, its status changes from active to “cron-running” in your MailBul web interface.

MailBul relies on pcntl extension to make sure if the process doesn’t exit nicely (because of some error or timeout) to restore the initial status of the server, that is, the active status so that the server can be selected next time when the cron job will run.

The thing is, the pcntl extension is something that doesn’t come with php and has to be installed separately so most of the time is likely that your php install doesn’t contain the extension. And because the extension is missing, MailBul might not be able to restore a proper state of the bounce server (MailBul has fallbacks mechanisms to cope with missing pcntl extension) and your bounce server will remain stuck in cron-processing mode and will not be picked for processing next time when the cron runs, remember, only bounce server having the status active are picked up for processing.
Bottom line, if you see your bounce server has the status “cron-running” for more than 30 minutes, then you can go to your applicaction

Backend -> Miscellaneous -> Emergency Actions and reset your bounce servers status so that they become active again.

Another thing is that, when processing bounces, MailBul uses php’s imap extension and even if your web instance of php contains the imap extension that doesn’t mean your command line (CLI) contains it too, matter a fact, i saw multiple servers that use php 5.3 as the web module(well, yeah php-fpm too, but you get the point), and php 5.2 as the CLI module.

You can verify this from command line, by running the command

php -v

which will tell you the version you are using in command line and if that is indeed using the CLI module and not the web module, because, i also saw the command line calling the web module, which is wrong since the web module is subject to timeouts and the such while the command line module isn’t (well, it shouldn’t anyway) thus is perfect for long running scripts.

To make sure your command line php contains the imap extension and the functions, the best way would be to create a php file on your server, say imap.php with the following contents:

<?php var_dump(function_exists('imap_open'));?>

then run in from command line with:

php imap.php

If the output contains the false word, then you don’t have imap installed and you have too.

If all the above look fine on your server, then make sure you don’t use services like gmail / yahoo / aol / etc as bounce servers. These services will limit the number of connections and might as well deny access to read the bounce boxes thus MailBul won’t be able to connect and read the emails.

Next, it’s always a good way to actually login for the bounce box and verify if there are emails there and if there are, and those are returned for your MailBul campaigns, look in the email source and make sure the following headers are there:

X-Mw-Campaign-Uid: 13CharsHash
X-Mw-Subscriber-Uid: 13CharsHash

Because MailBul uses those two headers to identify the campaign and the subscriber so that it can take proper actions against them.
If you don’t see those headers, then that’s bad, somehow those were stripped by the server that returned those emails into your bounce box, nothing much to do in this case.

Other things you can do, since the cron job for processing bounces is a simple command line script, you can actually call it from the command line as:

php {FULL_PATH_TO_APPS_FOLDER}/apps/console/console.php bounce-handler

and see how that goes, if it processes any bounce from your bounce box.

Some notes:
1. Because of the nature of processing bounces, because each email has to go through thousand of bounce rules and because connecting to imap/pop3 server is usually a slow action (like any other network action) you should make sure your command line php has enough memory to process your bounces. This, in tandem with the settings for bounces from Backend -> Settings -> Cron should be tweaked to match your server.

2) In MailBul, services like Amazon SES, Mandrill, Mailgun, Leadersend, ElasticEmail, Sendgrid not only work by using their smtp inteface, but they do have custom API implementation in MailBul and when you create a delivery server, you can use the API implementation instead of the smtp implementation:

The reason why you should use these instead of the SMTP alternative is because they are slightly faster when sending and because you don’t need bounce servers at all because MailBul will subscribe to certain webhooks and will receive notifications when an email bounces, marks you as spam, etc so you don’t need the memory intensive cron job to process bounces.
Please note that MailBul will connect to the given email provider and will create a webhook where the email provider will send data. The webhook is a url back to your MailBul application, something like https://www.MailBul-domain.com/index.php/dswh/X where X is the ID of your delivery server. This means that you don’t have to block incoming requests to these urls.
Each of these providers have their own area where they shown you which webhooks have been created and what events they will receive. Always make sure you check these areas to be sure the webhooks are created and the right events will be sent and of course see the history of the events they have sent in order to see if they actually have sent any info to your webhook url or not.

The post Seems that bounces aren’t processed, what can i do? appeared first on MailBul KB.

If you are on CentOS / RedHat / Fedora or derivates:

yum install php-imap

If you are on a Debian / Ubuntu or derivates:

apt-get install php-imap

If no packages are found, then consult your distro manual.

In case you are on a host where you don’t have command line access, if you have CPanel/WHM access, you can use EasyApache to compile php with imap extension.
Otherwise, you have to contact your host about the issue.

The post The IMAP extension is missing from your PHP installation. appeared first on MailBul KB.

This can happen for various reasons, such as:

1) You actually have never created a delivery server in the first place.

2) You did create a delivery server, but it is not confirmed.

3) You have a valid delivery server, but it is specifically assigned to a customer other than the one which this campaign belongs to.

4) You have a valid delivery server, system wide (not assigned to a customer), but in it’s settings, it is set to only send transactional emails.

5) You have a valid server for all emails, but the settings from Backend > Settings > Customers > Servers (same for group setting) dictate that the customer must add his own servers in order to send the emails.

6) Everything above doesn’t apply, but still you can’t send campaigns, but you can send test emails for example. Sometimes, the PHP version from the web server can be distinct than the one from command line. For example, apache can run php 5.6 but the command line version can be 5.0. The command line version is the version called by the cron jobs, the tasks that try to actually send your campaigns. To check this, from command line, the command php -v should show you the right php version number for the cli. Keep in mind that some delivery servers, such as amazon ses web api for example, require php >= 5.3.3.

The post Cannot find a valid server to send the campaign email, aborting until a delivery server is available! appeared first on MailBul KB.