Tag Archives: Mail

Bad Apple Mail—No Password!

This bug really burns me, because it’s been around forever, and Apple just isn’t doing anything about it.

Anyone who has used Apple Mail for more than a week has seen the following dialog box:

mailcantconnect

Of course, the natural response is to obey and type your password.

Don’t do it. 

Here’s why:

There are a half-dozen or so reasons why a mail transaction will fail. The mail server may be busy, hung, or dead. Your Wi-Fi may be down or your ethernet cable may be loose. There could be a network interruption in the greater internet somewhere between you and your mail server. Or, you could actually have supplied the wrong password for the account.

Unless your mail account is brand new, or you recently changed your mail password, the probability that this last choice is really your problem is vanishingly small.

However, that’s not Apple Mail’s opinion. “Couldn’t contact the server? Oh no, it has to be a bad password!” So Mail puts up this dialog box, inveigling you to type in your password again.

There is no upside to complying with this request. 

There are two probabilities here that absolutely dwarf all others: you will type in your password correctly, which won’t solve anything because your password was never the problem; or you will type in your password incorrectly, at which point you have now compounded your original problem by layering a worse one on top of it.

The real joker in the woodpile here is that one of the biggest reasons for typing in your password incorrectly is because you have actually forgotten your correct password. Now, a lost mail password can be retrieved using Keychain Access on your Mac… unless of course you have just overwritten it with a bad password because you responded to this idiotic query from Mail.  😡

The good news is that if you avoid thrashing at this juncture, you can still recover. Mail stores the POP/IMAP (incoming) account password separately from the SMTP (outgoing) account password, and in almost all cases known to man, they are the same password. Use Keychain Access to view the one you haven’t yet damaged, and beat this particular reaper.

Mail Mischief

[May 21 addendum: I’ve corrected this posting to identify the email service as Cox, not Gmail, and to append some additional information on defeating this bug.]

On this one, I suspected poltergeists.

A client called me complaining that she was periodically unable to send mail using her Cox account. We arranged a remote service session, and I found that the port and authentication type parameters for at least one of her outgoing server configurations were incorrect for Cox. I repaired them and verified that the result worked.

The next day, the client wrote to say she was having the same problems. I logged in again, and found that one of the port numbers had changed back to the same incorrect value, and the authentication setting had changed from “password” to “MD5 Challenge-Response.” I asked her if she changed those, and she said no, so I changed them back again and told her there would be no charge for the session.

Two days later, she reported to me that her service has been sporadic. Sometimes she could send mail, and sometime she couldn’t. Sometimes she could send it by switching to the SMTP server on her husband’s account, and sometimes she had to do the reverse.

I got back onto her system, and I found that the configuration values on her account have been changed again, and to values (like port 25) that don’t even work with Cox and never have.

I changed the broken account back to its proper value, whereupon the other one — which had just tested as working — immediately went out of whack!

I switched to it and found that the port had changed again… during the ten seconds that I was working on the other one.

Several times I ping-ponged back and forth, ports and authentication methods mysteriously changing themselves to the wrong values repeatedly during the course of a minute or so.

At this point I began to suspect malware, as improbable as that was. While I was downloading ClamXAV onto her system, I did a fast Web search on the symptoms. I was almost immediately rewarded with a posting describing exactly the same symptoms, and the fix for it.

It seems that in Yosemite, in the advanced section of the e-mail account configuration, there is a new checkbox called, “Automatically detect and maintain account settings.” Yosemite sets this on by default.

The downside is, it’s entirely brain-damaged. It’s just as likely to break your configuration as to maintain it, and is perfectly capable of doing either dozens of times a day, behind your back.

I turned that pesky option off, and again locked the port and password fields to working values. I’m hoping I’ll hear no more of this problem (at least from this client) until Apple finally fixes their buggy code.

[Addendum, May 21: Since posting this, I’ve heard from several other users with exactly the same problem. Informed speculation has it that it is Cox themselves who are feeding these erroneous values back into Mail, and not an Apple bug at all.

[Additionally, Yosemite also added a second “Automatically detect and maintain account settings” checkbox in the “Edit SMTP Server” area itself. If you don’t turn off both this flag and the one in Account / Advanced, the hits will just keep on coming. Make sure they stay off, as at least one user reports the one in Account / Advanced mysteriously turning itself back on right after he turned off the one in “Edit SMTP Server.”]