The Newsletter main configuration contains a number of parameters that must be set properly. Below you’ll find an explanation of each parameter and the pros and cons you can face while using it. Some parameters are required to get Newsletter work.
Please use the support forum to ask questions.
The sender is “who” is sending emails to your subscribers. With “who” I mean a name (for example your name if your’s is a personal blog or your brand name if it is a company blog) and an email address. Most of the time the best choice is to use an email address from your domain and possibly bonded to a real mailbox. A bad example is to use a gmail.com address as the sender’s email: some providers or generally the mail servers involved in delivering your messages can block them due to a domain mismatch. We experience that with some users.
It happens that setting a name on the sender data produces a message blocking it on a Windows based hosting space: you can leave that name empty if you want.
Remember to always use the diagnostic panel to send test email to verify if those settings are affecting the delivery.
You can setup a common header for your newsletters, the social links like Facebook, Google+, Twitter, Linkedin, YouTube and Vimeo, and a footer with your blog/company name, address and legal or copyright text.
Some themes may not use all these fields and/or have specific alternate configurations. All fields are optional.
Max emails per hour
Newsletter has a delivery engine which sends out emails as quickly as configured. This configuration is important since the provider does not like blogs on shared web spaces to send out tons of emails in a limited time frame. You should always ask your provider which is the limit they will tolerate.
Even on a private server, setting this limit to a reasonable value is a good idea to avoid saturating the server with queued email.
This limit is internally divided by 12 since Newsletter sends a batch of emails every five minutes. If you experience a lower delivery speed than set, remember that Newsletter can internally lower that value if it detects a PHP max execution timeout that does not let you send all planned emails in a run.
Enabling the logger at info level inside the diagnostic panel, and looking at the generated log file, you can see this situation clearly reported.
See the Delivery Engine page for more information about the delivering process.
The return path is an email address where an undelivered message should be returned. If it is a real mailbox you can check it to remove addresses from your list which are no longer reachable. You can even try the Bounce plugin on that mailbox to see if it able to detect those addresses and remove them from your list (it marks then as bounced).
We experienced several issues when this field was set, so if email do not seem to go out, try to blank it. If set, it should be set to an address in your domain (not gmail…).
The ‘reply to’ is an additional piece of information that can be added to messages, so those that want to reply to a newsletter will address their messages to the ‘reply to’ configured address instead of the sender address as seen above. As per the return path, sometime setting this field can lead to blocked email and you should set it to an address in your domain.
Enabling access to the editors means blog users with editor role can use the Newsletter. Every part of the Newsletter plugin from the configuration panels to the newsletter composer panel.
The API key is a secret sequence of characters that must be passed on while calling the externally exposed API of the Newsletter plugin. If that field is left empty, the API are disabled. The API are implemented with the code located in the “api” sub-folder if you need to look at it.
Custom CSS (for who know CSS…)
The Newsletter plugin generated forms can be styled with custom CSS, since their elements have a “class” attribute that lets you address them with a CSS rule. You can see the classes inspecting the code generated directly on your blog, or take a look to the generated from the “subscription form” panel.
The CSS are “injected” in the head of every blog page as is.
Email body encoding
Is the way an email message is internally encoded: usually the default should be good, but some providers have old mail servers with problems managing messages with long lines: try to set it to “base 64”, it’s the configuration I usually use.
PHP max execution time
Sending newsletters can be a slow process, it depends on the speed of the mail service. External SMTPs can be much slower than the standard method of sending emails from PHP.
PHP has a maximum execution time that, if exceeded, force the PHP engine to kill the process. Sending many emails can take longer than allowed.
Newsletter has an internal protection to avoid that and stops the delivery on a single batch if the maximum allowed time is reached. So, if you set an engine speed of 1200 emails per hour, hence 100 emails per batch, you can experience a lower number of emails sent per run. It’s due to that protection.
If you are confident enough to increase the maximum execution time of PHP, you can force the value (in seconds) using this configuration. Be aware: PHP running in safe mode will ignore this setting. To know the actual PHP preset value, see the system values on the diagnostic panel.
Since version 3.0, the SMTP configuration is available even on standard version. Most of the blog does not need to use an SMTP and most of the times bloggers does not have an SMTP which works better than their web space mail system.
If you want to use an SMTP I suggest to use some professional systems (and pay them). I’ve recently met SendGrid which I use to send most of may emails from blogs on shared hosting.
Connection to external SMTPs can be blocked by some provider. To name a couple, GoDaddy and 1&1. That block, if not removed, makes the SMTP unusable. I can do nothing.
If the provide allow external SMTP connections, it may allow them only with specific protocols and on specific ports. Most of the time the SSL connection on port 465 will work. Anyway SMTP services will usually have more than one option to connect with them, allowing different protocols on different ports. Ask them the list of available options and test them all.