We’ve added two new actions to the “rmap” API method:
- global: Changes domain to use the global valid user table.
- mode: Return the default action mode for a domain.
The API docs have been updated with the return values for the “mode” action.
We’ve added two new actions to the “rmap” API method:
The API docs have been updated with the return values for the “mode” action.
We’ve fixed a bug related to Internet Explorer 11 that would fail when trying to select filters to whitelist, preventing a whitelist entry from being added. Apparently we can’t use jQuery’s .on(‘click’) function and then expect to read the “checked” state from a button that was clicked. However it does work of .on(‘click’) is replaced with .change() then using .is(“:checked”) to see if it was selected/deselected.
These hooks were originally added based on customer feedback to provide a user interface element to indicate when a button was selected. There isn’t any functional dependency on jQuery – the forms will still submit if Javascript is disabled – but this also caused Internet Explored to fail to select the button completely even though it visually appeared selected. This issue only affected Internet Explorer on Windows.
We’ve added a new client validity check option called “Allow sender address to fail an RFC822 Address Check”. This option stemmed from an old feature request.
However, we are not supporting changing this option away from its’s “default” setting. The purpose of adding it as an option is to let customers that know why they would want to bypass this check (and understand the possible pitfalls) to have the option to do so. Rollernet does not recommend or support changing this setting. You’ll find it at the very bottom of the Client Validity Checks.
The AHBL DNSBL is closing down and emptying its DNS zones. As such, we will be removing all *.ahbl.org configurations from customer DNSBL settings.
See the announcement at: http://www.ahbl.org/content/changes-ahbl
The Heartbleed Bug is a major vulnerability in the OpenSSL library. OpenSSL is extremely popular and is used as the cryptography library behind the scenes for countless secure applications. By now you’ve probably heard about it and its widespread implications. We’re not going to rehash it here, see: heartbleed.com
Roller Network uses Debian Linux as the OS of choice for our servers. However, we do not generally stay on the “bleeding edge” of updates, and in this case that has served us well.
OpenSSL 0.9.8 is not, and has not been, vulnerable to “heartbleed”. Only the newer OpenSSL 1.0.1 through 1.0.1f is vulnerable.
So where does that leave us? The good news is that we were still Debian 6.0 “squeeze” at the time of this security fiasco because we don’t like to jump right into the latest release for the sake of updating. The Debian security team still provides security updates to the previous stable release (also known as “oldstable”) for a period of time, so we’re in no rush to upgrade. Specific software that we do want to have newer versions of are either obtained from Debian backports or compiled manually. We like to take a wait-and-see approach before upgrading Debian distributions.
Here’s a rundown of the major services:
This is great news for our customers: at no time were any password-accepting Roller Network servers running a distribution that was affected by “heartbleed”. We did have an internal server in the office running Debian 7.0 and it’s been patched, SSH keys regnerated, and its SSL cert (signed by our internal CA) reissued.