How to resolve Mail SMTP errors in OS X 10.10.4 and iOS 8.4
A change in the way OS X 10.10.4 and iOS 8.4 handles security keys has caused a number of users -- specifically those using Gmail -- to see SMTP send failures and even app crashes. Luckily, there's an easy fix for both users and system admins looking for a permanent server-side solution.
The issue was first noted by users on Apple's Support Communities forum shortly after Apple released OS X 10.10.4 and iOS 8.4 on June 30. Sporadic account connection issues, inability to send email from specific servers and complete Mail shutdowns were reported.
Apple offered a possible explanation in a support document one day later, saying that both OS X 10.10.4 and iOS 8.4 provide increased security against a certain TLS vulnerability called "Logjam." To protect users, devices updated to the latest OS versions no longer connect to servers or webpages using "weaker" Diffie-Hellman encryption, defined as having a group size of less than 2,048 bits.
As a result of the poorly documented change, users might encounter problems when connecting to enterprise class Wi-Fi (802.1X), secure email connections (SMTP), secure web connections (HTTPS) and secure Internet printing (IPP over TLS/SSL), Apple said.
Support Communities forum members have discovered a number of workarounds, including the disablement of SSL, which is not recommended considering it removes a layer of protection.
A more viable fix can be accessed by navigating to Preferences option in the Mail for OS X menu dropdown. In the Settings window, click on the Accounts icon and select the email account experiencing issues.
Next, click on Advanced in the resulting pane, toggle the check box next to the "Automatically detect and maintain account settings" item line and restart Mail. Upon opening, navigate back to the affected account and tick the box if you turned it off, or confirm that it remained checked upon restart.
For system administrators, Apple again notes servers should employ a group size of 2,048 bits or greater when using Diffie-Hellman key exchange. Apple Support Communities forum member "PeetDeVos" offers the following suggestion:
The issue was first noted by users on Apple's Support Communities forum shortly after Apple released OS X 10.10.4 and iOS 8.4 on June 30. Sporadic account connection issues, inability to send email from specific servers and complete Mail shutdowns were reported.
Apple offered a possible explanation in a support document one day later, saying that both OS X 10.10.4 and iOS 8.4 provide increased security against a certain TLS vulnerability called "Logjam." To protect users, devices updated to the latest OS versions no longer connect to servers or webpages using "weaker" Diffie-Hellman encryption, defined as having a group size of less than 2,048 bits.
As a result of the poorly documented change, users might encounter problems when connecting to enterprise class Wi-Fi (802.1X), secure email connections (SMTP), secure web connections (HTTPS) and secure Internet printing (IPP over TLS/SSL), Apple said.
Support Communities forum members have discovered a number of workarounds, including the disablement of SSL, which is not recommended considering it removes a layer of protection.
A more viable fix can be accessed by navigating to Preferences option in the Mail for OS X menu dropdown. In the Settings window, click on the Accounts icon and select the email account experiencing issues.
Next, click on Advanced in the resulting pane, toggle the check box next to the "Automatically detect and maintain account settings" item line and restart Mail. Upon opening, navigate back to the affected account and tick the box if you turned it off, or confirm that it remained checked upon restart.
For system administrators, Apple again notes servers should employ a group size of 2,048 bits or greater when using Diffie-Hellman key exchange. Apple Support Communities forum member "PeetDeVos" offers the following suggestion:
If problems persists, the next recommended step is to contact your email provider and request Apple's new 2,048-bit cryptographic protocol be instated.Sendmail server on CentOS / Linux:
I added the following to the /etc/mail/sendmail.mc file before re-make (make -C /etc/mail) and restart of sendmail only (service sendmail restart). It instantly worked:
dnl # Added to resolve issues with Mac Mail
define(`confDH_PARAMETERS',`/etc/mail/certs/dh_2048.pem')
Before you do that, create the dh_2048.pem file using (openssl gendh -out dh_2048.pem -2 2048) in the relevant path (/etc/mail/certs or what you use).
Comments
Ooooor, Apple could just support the standards mail servers use instead. Sounds like a case of the tail trying to wag the dog. The client is subservient to the server Apple.
"If problems persists, the next recommended step is to contact your email provider and request Apple's new 2,048-bit cryptographic protocol be instated."
Ooooor, Apple could just support the standards mail servers use instead. Sounds like a case of the tail trying to wag the dog. The client is subservient to the server Apple.
Dear Google, would you please do what Apple says.
Thanks.
"If problems persists, the next recommended step is to contact your email provider and request Apple's new 2,048-bit cryptographic protocol be instated."
Ooooor, Apple could just support the standards mail servers use instead. Sounds like a case of the tail trying to wag the dog. The client is subservient to the server Apple.
Apple users are so plentiful that this will be very effective for the few who haven't done it already.
For me Mail is working better with 10.10.4. In 10.10.3 I was having niggling issues with Gmail retrieving email. 10.10.4 fixed things for good.
"If problems persists, the next recommended step is to contact your email provider and request Apple's new 2,048-bit cryptographic protocol be instated."
Ooooor, Apple could just support the standards mail servers use instead. Sounds like a case of the tail trying to wag the dog. The client is subservient to the server Apple.
This isn't just Apple... it's industry-wide. It was found that some *highly* insecure keys were still supported in OpenSSL as a holdover from when strong encryption was illegal to export from the US, and with a little work, it might be possible to get . So these keys were considered fairly weak in the mid 90's; you can imagine how useless they are today. So the servers that "broke" are not only using the old, useless keys... they aren't even capable of using the newer, decently strong encryption, and are probably still configured to comply with that export law that was repealed in the late 90's. Here's an article on Ars with more info.
BTW, this also affected my VPN software when they updated the SSL engine. Turns out my ASUS router had generated a too-small prime when it created the keys, so I manually generated one to replace it. Took a while to track down the problem, but only a minute or so to fix it (mostly spent waiting for the prime to be created.) No reconfiguration of the client side was necessary.
Edit: After reading the article again, it sounds like Apple Mail might just be stuck using the smaller prime and simply re-configuring the mail client convinces it to use the better version. (That's probably how you fix iOS, too, but the article weirdly doesn't say anything about that?) If that's the case, it is indeed Apple Mail misbehaving, but it still has nothing to do with Apple not supporting industry standards.
My problem is recently when I open Apple mail, my mail accounts don't load sometimes. Probably 80% of the time they load but sometimes they don't. Weird. I think it ties into this same issue somehow.
If that's the case, it is indeed Apple Mail misbehaving, but it still has nothing to do with Apple not supporting industry standards.
Microsoft set Windows to fail at under 1024 bit DH, Google Chrome will give an error message at 1024. It will be upgraded to 2048 at a later time. Their metrics say this breaks less than 1% of hosts. There is always a compromise between security and usability.
Stupid Apple mistake 1 is somebody at Apple just read "use 2048 bit DH" without evaluating the consequences, and stupid Apple mistake 2 is they didn't provide an error message or method of feedback, and stupid Apple mistake 3 is there's no way of overriding the limit.
Incorrect link. Do you have the right one?
Oops! Fixed.
http://arstechnica.com/security/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-and-mail-servers/
Microsoft set Windows to fail at under 1024 bit DH, Google Chrome will give an error message at 1024. It will be upgraded to 2048 at a later time. Their metrics say this breaks less than 1% of hosts. There is always a compromise between security and usability.
Stupid Apple mistake 1 is somebody at Apple just read "use 2048 bit DH" without evaluating the consequences, and stupid Apple mistake 2 is they didn't provide an error message or method of feedback, and stupid Apple mistake 3 is there's no way of overriding the limit.
1) Yeah, they kind of jumped the gun, but that is where everyone is headed fairly soon.
2) This is SOP for Apple. Apple is doing well to even let you know there WAS an error, and Microsoft just spits out gibberish (but at least there's an error number you can google) I wish one of them would figure out a middle ground.
3) Allowing the use of a key that can be cracked in seconds by a *single* modern CPU is arguably worse than no encryption at all. (False sense of security, etc.) This is the one thing they did get right, imo.
"I talk to 25 people a day about Mail and you are the first to say this" Apple is getting more and more careless and more and more delusional in their denials. I brought up the screensaver reverting to National Geographic that 10.10.4 DID fix finally. "That was a known issue" Well NUMEROUS Apple advisors had me trying everything to fix it before and denied it WAS an Apple issue!
"If problems persists, the next recommended step is to contact your email provider and request Apple's new 2,048-bit cryptographic protocol be instated."
Ooooor, Apple could just support the standards mail servers use instead. Sounds like a case of the tail trying to wag the dog. The client is subservient to the server Apple.
Of course Apple is leading the way. They always have. You think that Apple should support the status quo, and not force the industry to change, for the better?
Of course Apple is leading the way. They always have. You think that Apple should support the status quo, and not force the industry to change, for the better?
If Apple users find their devices no longer do what they as users want them to do, then Apple has done them a disservice.
If Apple users find their devices no longer do what they as users want them to do, then Apple has done them a disservice.
Tell that to floppy disks and CD drives