If you’ve had trouble sending to Gmail addresses today or yesterday (December 14 or 15), where an address that you know is valid bounces back with “The email account that you tried to reach does not exist”, the problem isn’t you, or us. Gmail had a problem that caused this for all senders, seen on their status pages yesterday and today, with the latter confirming “Affected users received a bounce notification with the error “The email account that you tried to reach does not exist” after sending an email to addresses ending in @gmail.com”.
They also confirmed it on Twitter:
They say the problem is resolved now, so if it happened to you, it should work if you try sending again.
We’ve improved how our “My Account” control panel rejection of email addresses works.
Previously, if you added an e-mail address to the reject list, the “Return-Path” (aka bounce address) header of each incoming message was checked for matches. This was sufficient for most messages, but some messages use a different address in the “Return-Path” header and the “From” address header, which could be confusing.
As of today, both headers (the “Return-Path” header and the “From” address header) are checked when matching reject list entries, making it more reliable.
As always, don’t hesitate to contact us if you have any trouble or questions.
A couple of customers have recently contacted us about problems with Outlook 2011 for Mac when it’s configured to make SSL connections.
Outlook 2011 for Mac has a bug: It tries to use the long-obsolete “SSLv2” protocol that is no longer supported on modern mail servers, including ours. If your network also uses a very common kind of firewall that prevents “client-initiated SSL/TLS session renegotiation”, SSL connections will simply fail.
The best solution to this is to upgrade to a modern version of Outlook. Outlook 2016 for Mac, for example, doesn’t have this problem.
Read the rest of this entry »
If you install a script that sends mail, that script should let you choose the address it sends from. Unfortunately, some scripts don’t offer that feature, instead using a default sender address that on our systems looked like “From: firstname.lastname@example.org” until now.
The inability of these scripts to specify a sender address has become more of a problem as email reputation and security systems like DKIM are deployed.
To help with this, we’ve enhanced our email system to allow you to specify the sender address these scripts use. The “How can I change the default address?” section of our page about script addresses has more details.
By the way, if you use a script like this and you don’t choose an address, it will default to the slightly different “From: email@example.com” from now on. But we recommend that anyone who uses these kinds of scripts choose a real address instead, which will ensure other people see only your own domain name.
This post describes a technical change that most customers can ignore; we’re posting it for advanced users who may be interested.
If you have hosting service with us, we publish a default SPF record in your DNS zone if you don’t provide one yourself.
Read the rest of this entry »
Between 9:50 PM Pacific time August 9, and 10:49 AM Pacific time August 10 (today), a third-party virus scanner we use incorrectly marked some Microsoft Word attachments as being a virus called “Win.Exploit.CVE_2016_3316-1” and returned them to the sender. This affected several of our customers.
We’ve “whitelisted” this virus pattern to prevent this from happening. However, our logs show that many other ISPs are still incorrectly rejecting this “virus pattern”, so you may still see some rejections if you send Word attachments outside our network until the other ISPs also fix it.
We apologize for the inconvenience this caused any of our customers.
For a long time, our mail system has blocked many malicious filename extensions.
Recently, we’ve seen an increase in “.js” files that spread various forms of malware. These change their “patterns” often enough that they’re sometimes not detected by virus scanners.
Legitimate “.js” files are common in e-mail, so it’s impossible to block them outright. (They’re often sent as part of a package of website files — for example, a zipped copy of the WordPress files contains them.)
However, legitimate “.js” files almost always occur as part of an archive containing other files. They almost never occur alone, as they do in the malware versions.
Because of that, our e-mail system now blocks “.zip” files that contain only a single “.js” file, on the assumption that they’re almost certainly malicious.
We don’t expect this to cause any problems, but as always, don’t hesitate to contact us if you have any questions or trouble.
Recently, we’ve had quite a few customers write in to complain that their copy of Outlook 2016 is behaving incorrectly: it is either deleting messages from the server when it is not supposed to do so, or it is downloading duplicate copies of mail from the server. This happens for POP accounts, not for IMAP accounts (which is what we normally recommend customers to use).
These problems happen because of a bug in Outlook 2016. Microsoft has a Web page that explains the problem as well as the solution (upgrade Outlook).
We’ve had reports of an error message like this in Outlook when using Windows 10:
error (0x800CCC13): Cannot connect to the network. Verify your network connection or modem.
If this happens to you, it’s because of a problem with Windows 10, not with Outlook or our servers. According to the Microsoft page about it, updating Windows 10 should fix it. If it doesn’t, they suggest using a “workaround” to repair corrupted files on your computer.
This post describes a small technical change to the way e-mail is stored on our servers. The change is unlikely to affect anyone and does not affect normal e-mail access at all — we’re documenting it just in case any customer is doing something very unusual.
Last year, we started compressing some stored mail on our servers, and our page about mail storage mentioned that compressed mail files would have a capital “Z” in the filename.
Our servers now compress all new mail, and as a side-effect of that change, compressed files won’t always have the “Z” in the filename. The page has been updated to reflect that.
As it says, we never recommend accessing the raw mail storage files anyway: All mail access should always be done through standard SMTP, POP or IMAP protocols. Doing things that way will ensure that changes the mail storage format won’t affect you.