Google malware warnings
Google is fairly aggressive about checking for malware on Web sites. When they find a site distributing malware, they make a note of the details and try to warn visitors.
Google is fairly aggressive about checking for malware on Web sites. When they find a site distributing malware, they make a note of the details and try to warn visitors.
The PHP developers recently released versions 5.4.31 and 5.5.15 that fix several bugs. We’ve updated PHP 5.4 and 5.5 on our servers as a result.
One of our customers asked if multiple domain names hosted with us are vulnerable to “website cross-contamination”, a nasty security problem that can happen at many hosting companies when two different sites share the same “account”.
The answer is no. We intentionally handle multiple hosted domain names differently from the way most hosting companies handle extra hosted domain names, avoiding the problem.
Over the last few days, we’ve been tracking an ever-increasing distributed attack on the WordPress xmlrpc.php service.
We’ve previously seen and blocked attacks on this file that tried to post spam comments or act as a denial of service amplifier, but this attack is different: it tries to guess WordPress usernames and passwords.
As a result, we’ve applied more aggressive blocking than usual to the attack. It’s remotely possible that the blocking could cause legitimate third-party WordPress “apps” and services to be unable to access your blog (although it can’t cause problems when just visiting WordPress in a normal Web browser); don’t hesitate to contact us if you’re one of our customers having trouble.
Just so it’s clear, we’ve blocked this attack for all our hosting customers. But the rest of this post has some technical details that may help other people trying to do the same.
We often get reports from customers saying they’ve been blocked from their WordPress sites with a strange generic error message or blank page.
When we investigate, it’s common to find that it happened because they installed a security plugin that has made a mistake — a “false positive” — and blocked the site owner.
A customer recently reported problems when forwarding mail sent from a “@cs.com” CompuServe address to a Yahoo or Gmail address. Yahoo completely rejects the forwarded message and Gmail puts it in a “spam” folder.
This is caused by a misconfiguration at cs.com, and happens whenever anyone, anywhere, forwards @cs.com mail. It’s not related to our service in particular. However, we’ve reported this to cs.com in the hope that they’ll fix it.
Until they do so, there’s no way to avoid this problem except by having the sender send mail directly to the final destination address, or converting the forwarding address to a mailbox. (This problem is another example of the general rule that “a mailbox is usually more reliable than a forwarding address, because forwarding involves two places where things can go wrong instead of just one”.)
The PHP developers recently released versions 5.4.29 and 5.5.13 that fix several bugs. We’ve updated PHP 5.4 and 5.5 on our servers as a result.
We recently explained how to avoid DMARC mail delivery problems with the “Gravity Forms” WordPress plugin.
We’ve added a support article explaining how to avoid DMARC mail delivery problems with the similar “Contact Form 7” plugin, too.
If you use either of these plugins and you’re seeing mail rejected with errors about “DMARC”, the links above will help you fix it.
If you use the Gravity Forms WordPress plugin, be sure you don’t set it to send mail “from” the e-mail address of the person filling out the form. If you do, you’ll have trouble due to recent “DMARC” anti-forgery changes some companies (including AOL and Yahoo) have made.
To avoid problems, make sure that Gravity Forms (and other such forms) send mail “from” the Web site domain name the form uses. For instance, if your Web site is at www.example.com, you could send mail from “notifications@example.com”. Here’s a helpful page that explains how to properly set up the Gravity Forms address with DMARC in mind.
By the way, this is just a specific case of the general rule of “don’t send mail from addresses you don’t own”. The simple way to think of it is that you’re not (say) AOL or Yahoo, so your Web site shouldn’t send mail claiming it’s from aol.com or yahoo.com addresses. AOL and Yahoo don’t want other people doing that. Always send mail only from your own domain name.
We’ve updated the MySQL database software on our servers from version 5.5.35 to 5.5.37 for security reasons.
Customers should not notice any changes, as the update merely fixes bugs and doesn’t introduce new features. But as always, don’t hesitate to contact us if you have any questions.