Server Software and Configuration Services
New MailScanner Front-End (MSFE) v4.13
Changes:
- Added fix for the latest cPanel branding changes for the new x3 API which broke the end-user UI for MSFE
Note: This update is for cPanel v11 only
Changes:
Note: This update is for cPanel v11 only
Changes:
Changes:
Note: This update to MSFE is only available to those running cPanel v11 and later
Changes:
The new Incoming Scanning only option is now available within this package. After upgrading MailScanner you can easily switch to use Incoming Scanning Only with:
You can switch back at any time to In/Out Scanning using:
Limitations on In Scanning Only option:
We’re considering an alternative method for configuring MailScanner on cPanel servers, possibly in addition to the current method, or as a replacement.The new method only scans incoming email. Outgoing email from the server is passed directly through exim (as if MailScanner were not installed) and can offer significant improvements to server performance, especially for those that host large mailing lists.The current default when installing MailScanner using our script is to only scan incoming email anyway, but all email mst still pass through MailScanner whether it is scanned or not.It would help us decide whether to pursue this (we will have to get cPanel to make a configuration option change for exim to do this) if you could vote in this poll:
Option | Votes | % |
---|---|---|
Incoming emails only (current default)? | 111 | 72.5 |
Incoming and Outgoing emails? | 42 | 27.5 |
Changes:
Changes in v1.05:
Changes in v1.06:
Just experienced an issue in cPanel v11 where root crontab emails aren’t being delivered. The jobs in /etc/cron.*/ work OK, but jobs in /var/spool/cron/root are failing to send emails to the root forwarder. It’s most likely a bug in the cPanel exim routers in v11.In the meantime, if you experience this problem, you can work around it by adding:
Then at the top of the root crontab set MAILTO= to your email address, e.g.:
There is a bug in many rules that used to work fine for versions of SpamAssassin prior to v3.2.0. This new release affects some regex traps when non-ascii characters are pushed through them. The generated error causes the SpamAssassin checks in MailScanner to loop which can result in extraordinary high server loads.The included SpamAssassin rules with v3.2.0 appear to be fine (to our knowledge at present) but some third-party ones are not. These include some from the SARE repository used by the openprotect service:http://www.gossamer-threads.com/lists/spamassassin/users/100450It’s worth noting that we have only seen this issue arise on one server so far since the release of SpamAssassin v3.2.0.If you experience this problem, or want to avoid it, you will have to disable the openprotect rules from our MailScanner package script /root/sa_rules.shYou can do this by commenting out the appropriate line so that the file looks like:
You then need to remove any download rules using:
You can then re-enable by removing the # in the openprotect line in /root/sa_rules.sh once these issues have been fixed.Of course, the downside to all this is that SpamAssassin will be less able to assign higher scores to likely spam.