This is our spam / virus filter update for customers on the mx1 / mx2.tnpw.net filtering cluster. The information is brought to you by our vendor, SpamExperts.
What's new this week:
Command-line Bulk Protect for cPanel & Odin addons:
With today's update of the cPanel and Odin Plesk addons, we have added an option to run the initial "Bulk Protect" option directly from the command line. This is especially useful for setups with a large number of domains, where using the GUI for this operation, it can sometimes be time-consuming. Information on how to use this can be found on our Knowledgebase here and here.
New password policy available
A frequent error that people make when selecting a password is to use a common word - maybe just putting in some case changes, like "elEphanT". These passwords are very insecure, and easily found by any automated system. As such, you may wish to prevent your web interface users from using such passwords, and you can now do this. We’ve added a new optional policy in the "User Settings" page, "Allow dictionary words". Like all the other policies, this will apply to any users at that level, and lower (so if you set this to "no" at an admin level, all their sub-admins will be forced to have it set to "no" as well). We prevent using passwords from whichever language the user is currently using, so that they aren’t forced to know words in all the languages that we support.
Per-day Outgoing user limit
You are able to configure a limit for the number of messages that an outgoing user may send; you specify a limit in terms of per month, per week, per day, per hour, and per minute (or disable the limits). Previously, the per-day limit was not exposed in the web interface, although the other limits were. We now expose all of these options for your convenience. Note that the existing per-day limit is set extremely high, so that it does not unexpectedly trigger, and the limit does not change with this update.
Protection against empty-sender bounces
We do not verify the recipient address for outgoing messages prior to accepting the message (as doing so can cause problems with some systems). However, in the case of messages that do not have an envelope sender address ("null sender" messages), this can lead to large build ups in the queue, as the messages get frozen with periodic retries. As of this update, we will do recipient address verification for all outgoing messages that do not have an envelope sender; this means that if you do have users that are sending such messages, they need to ensure that the recipient address is valid (of course, they should be doing this anyway).
Changelog:
Filtering (services):
Front-end / GUI:
Plugins & Integration tools:
For more information, please do not hesitate to contact us.