Q: os x update 10.10.4; mail won't send 6/30/15

elbles wrote:

(...)

I'd venture a guess that this is Apple responding to Logjam (or, more accurately, Apple nudging system administrators to patching/fixing their systems):

That is exactly what annoys me. It is not nudging it is bullying in the worst way. The aforementioned fix, which helped me as well, is something we sort off found out by listening to the grapevine and tray&error. That is not a professional behaviour in any way! Because out of the available reactions OS X gives you, one can not deduce the fix.

There should be something popping up like "vulnerable TLS - I won't connect", and not the "Your internet is broken" from the connection doctor.

So all those who don't control their mail server (and that is most likely somewhere around 10% of the people having problems) and can do the fix themselves, they have to contact their servers administrator with something like "My Apple mail doesn't work anymore and there is this thread where some geeks say it is some dh-thingy which has to be bigger. Nobody really knows if it is the problem, but can you fix it please!" instead of "Apple addresses the logjam problem, lease upgrade your system according to the current standards"

But hey, it is not like as if email is an important part while using computers these days...

None of the "fixes" mentioned here has helped... my only hope is that they get this fixed quickly.

I had the sending problem - could not send to my ISP nor to Gmail.  Everything just sat in my Outbox.   Last night  I rebooted and...    all the mail just went out on its own.  I'm guessing a lot of folks with this problem have rebooted several times..   but just in case you haven't...   might be worth a try. 

I didn't mess with any files - I already had the "Automatically detect and maintain account settings" option selected.   I did use the Mailbox -> Rebuild option on each account - which didn't fix anything.   At least not until the reboot.

Unfortunately I don't think this is going to get fixed.

I'm already looking to upgrade out IMAP server, which should have the latest protocols that Mail.app will accept. The problem (and I'm still not 100% sure about this until I have some time to setup the lab IMAP server and verify) has to do with older servers using deprecate digests and cyphers. I doubt Apple is going to go back on this.

If this is indeed is about not allowing deprecate encryption than it IS really sad. I agree that this should be a user/admin choice, not forced down our throats like some infant who doesn't want to eat his vegetables.

Here's what the logs from a working 10.9.5 Mail.app look like (connection doctor):

READ Jul 02 14:58:51.288 [kCFStreamSocketSecurityLevelTLSv1_0] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6000006d6ea0 -- thread:0x608000261a80

235 2.0.0 OK Authenticated

WROTE Jul 02 14:58:51.288 [kCFStreamSocketSecurityLevelTLSv1_0] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6000006d6ea0 -- thread:0x608000261a80

QUIT

INITIATING CONNECTION Jul 02 14:58:57.327 host:postoffice.inksystems.com -- port:587 -- socket:0x0 -- thread:0x608001069780

CONNECTED Jul 02 14:58:57.343 [kCFStreamSocketSecurityLevelNone] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6080006d3b00 -- thread:0x608001069780

READ Jul 02 14:58:57.355 [kCFStreamSocketSecurityLevelNone] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6080006d3b00 -- thread:0x608001069780

220 postoffice.inksystemsinc.com ESMTP Sendmail 8.14.2/8.14.2; Thu, 2 Jul 2015 14:58:57 -0700

WROTE Jul 02 14:58:57.371 [kCFStreamSocketSecurityLevelNone] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6080006d3b00 -- thread:0x608001069780

EHLO [12.238.189.78]

READ Jul 02 14:58:57.372 [kCFStreamSocketSecurityLevelNone] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6080006d3b00 -- thread:0x608001069780

250-postoffice.inksystemsinc.com Hello [12.238.189.78], pleased to meet you

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-8BITMIME

250-SIZE

250-DSN

250-AUTH GSSAPI

250-STARTTLS

250-DELIVERBY

250 HELP

WROTE Jul 02 14:58:57.372 [kCFStreamSocketSecurityLevelNone] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6080006d3b00 -- thread:0x608001069780

STARTTLS

READ Jul 02 14:58:57.373 [kCFStreamSocketSecurityLevelNone] -- host:postoffice.inksystems.com -- port:587 -- socket:0x6080006d3b00 -- thread:0x608001069780

220 2.0.0 Ready to start TLS

The problem is at the end of this process 10.10.4 no longer responds, as if it can not negotiate the cypher to use.

Not that I don't get that DH 512 is now easily hackable, but I mean, do I really care? Our email information is not that important that a hacker would go to all the trouble to setup a man in the middle attack, and we really have nothing to hide form the likes of the NSA so, what's the big deal ??

I fixed it!

I downloaded Postbox, spent the $15 and have scrapped Mac Mail.

BOOM, there's your answer folks.

Seem the issue is that the password is not being saved for SMTP servers. I was able to get it to connect by creating a new SMTP server and not assigning it to any account. Sometimes this connect once and not the second time, sometimes it worked until I associated it to an email account, and sometimes it still never connected. BUT, every time I create it and go back in to the Advanced tab the password is not there. On another machine that also have Mail 8.2, but does not have this issue, the password is always there when I open the SMTP settings. Seems some installs of Mail 8.2 are not saving the SMTP password.

Sorry, don't have a solution, but have been able to narrow down the problem.

Hi all, had the same problem - IMAP was fine (mails are coming in) but can't connect to SMTP.  Tried all the above but didn't work until this.

1. Goto your mail preferences, Accounts and Edit the SMTP server list.
2. Make a note of the SMTP configuration (server name, port, etc).
3. Click on the '-' minus sign to remove the SMTP configuration
4. Click on the '+' add sign to add a new SMTP configuration and use the same configuration as point 2.

Got my email receiving and sending after this . Hope it works for you.

I fixed the problem. I went into Internet Accounts in Preferences. I highlighted 1 Gmail and 1 AOL account. Minus them both. Deleting those also deleted them out of the mail app (so back stuff up). Next I recreated the Internet Accounts for those same Gmail and AOL email addresses I just deleted. Finally, went back into "Accounts" in Mail and now the Outgoing Mail Server shows Gmail (or AOL). All I had to do is go into the rest of the accounts and change the Outgoing Mail Servers back and it all seems to work.

You can check your server's DH configuration with

openssl s_client -crlf -connect smtp.aim.com:465

Look for "Server Temp Key" ("Server Temp Key: DH, 1024 bits").

Does work on most Linux, but doesn't seem to work on Yosemite, because OpenSSL >= 1.0.2 is required. Earlier versions of the client do not display this information.

Thank you!!! Your post gave me the hint I needed to bring this hellish day to an end. And thanks also to elbles for the link with the details.

After upgrading to 10.10.4 all 3 of my regular Google/Gmail IMAP accounts were not connecting (both IMAP and SMTP connections failed). Up to 10.10.3 I needed to have the boxes for "Automatically detect and maintain account settings" UNCHECKED to be able to connect. Now checking those boxes in both Accounts-Advanced and in the SMTP server list - Advanced has restored access. It sounds like others have tried this "solution" unsuccessfully so maybe the problem is deeper...just wanted to share one data point.

The same problem here. After upgrading to 10.10.4 sending via SMTP does not work. I think the problem is the password. It is not saved correctly. See the protocol:

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] >> EHLO  (19 additional bytes)

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-my-server.de

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-PIPELINING

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-SIZE 110000000

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-VRFY

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-ETRN

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-AUTH PLAIN LOGIN

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-AUTH=PLAIN LOGIN

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-ENHANCEDSTATUSCODES

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250-8BITMIME

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 250 DSN

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] >> AUTH  (5 additional bytes)

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 334  (12 additional bytes)

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] >>  (12 additional bytes)

Jul  3 15:38:52 garion Mail[46508] <Debug>: [0x60000017ee40] << 334  (12 additional bytes)

Jul  3 15:38:53 garion Mail[46508] <Debug>: [0x60000017ee40] >> * (0 additional bytes)

The last line is where the client sends the base64 encoded password. This is empty. Mail simply does not save the password if the mech is AUTH LOGIN/PLAIN.

So, I try to active MD5 on my server. Let's see what happens.

The password correctly saved in Keychain. But Mail sends an empty password

NOTE: I fixed the Sending Issue on Server side.

I've had the same issue as all (10.10.4), but the issue was on the Mail Server, not Apple Mail.  This was a big pain, but I was able to fix the issue on the Mail Server side (since I'm the administrator).  This post is for Mail Server Administrators using Sendmail.

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).

I hope this helps,

Regards,

Peet

A new 2048 bit DH key is not always the solution. My server already has a 2048 bit DH key (I changed it shortly after logjam was in public).