Apple Knowledge Base article on ‘server rejected password’ error message in Mail

Posted by Pierre Igot in: Macintosh
June 24th, 2004 • 1:38 am

Apple has a new Knowledge Base article on Mac OS X’s Mail and the “The server rejected the password” alert, which can appear even when the password is correct.

Mac OS X Mail: “The server rejected the password” alert, even with correct password

Mail might tell you this, even when you’re using the correct password:

“The server {server name} rejected the password for user {username}. Please re-enter your password, or cancel.”

This message may appear several times while trying a correct password.

This can happen if the mail server is not available for authentication or cannot be contacted. Click Cancel, then wait a few minutes. After waiting, choose Go Online from the Mailbox menu, then enter the same password.

If this doesn’t help, you may indeed by using the wrong password, or it may have been changed. Check with your Internet service provider about how you can reset it, if necessary.

I am all too familiar with this erroneous alert myself.

Unfortunately, the Knowledge Base article fails to address some core issues. The first one is that no alert message in Mail should ever lead the user to think that his password is incorrect when it is in fact correct. In my experience, far too many people are unsure of what their password is (they entered it once a long time ago and haven’t had to use it since) and are likely to take the erroneous alert message literally and try to retype their password, replacing the correct one with a wrong one. The fact that the alert message automatically comes with a text field to type the password (which Apple doesn’t mention in this article) is another embarrassment, because it further encourages this behaviour.

Apple might claim that the phrasing of the alert is ambiguous enough (it doesn’t actually say that the password is wrong, only that the server rejected it), but ambiguity is not an appropriate approach when it comes to password/security issues. Things need to be 100% clear and the alert should only appear when the password is actually wrong.

Of course, the issue is whether Mail can actually distinguish, behind the scenes, between an unresponsive server and one that responds by rejecting the password. I believe that it can. In my experience, this erroneous alert occurs most often in low-bandwidth situations (when a big download is taking place and consuming all available bandwidth, for example), in which case the mail server is not responding at all. I am quite sure that, if the server were responding, it would actually send a special code/command indicating that the password is wrong, if that’s the case. But no response from a server doesn’t mean that the password is wrong. In Mac OS X’s Mail, unfortunately, it often does.

The other problem with the article is the phrasing of the solution. Apple says that the user should click on the “Cancel” button and then “wait a few minutes” and try again. This ignores the fact that, if the error is due to a low-bandwidth situation, there is nothing that guarantees that the bandwidth situation will improve in “a few minutes“. On a modem connection, big downloads can take hours! In addition, the user shouldn’t have to “cancel” the action of retyping the password, because the action shouldn’t have been initiated in the first place!

This boils down to a more general problem with how Mac OS X handles low-bandwidth situation. The only appropriate approach here would be to tell the user to wait until the bandwidth situation improves. But the user has no way to know what the bandwidth situation is unless he has a direct modem connection and he keeps the Internet Connect application window with the Receiving and Transmitting bars open at all times. (I have an indirect modem connection through my AirPort Base Station, so I cannot monitor modem traffic in Internet Connect. I have to use MenuMeters for this.)

Before trying to re-enter his password, the user should make absolutely sure that the problem is not due to a low-bandwidth situation. But Mac OS X offers no easy way to do that, and really Mac OS X itself should be able to tell if there is a bandwidth problem and not mislead the user with an erroneous alert message. How likely is it really that the user’s password might be incorrect or “have been changed“? For most people, in most situations, their password never changes unless they decide to change it themselves.

In other words, this Knowledge Base article is disappointing, because it seems to accept the existence of this erroneous and misleading behaviour as a fact of life under Mac OS X that Apple can do nothing about, and also because it is misleading itself in the solution offered. Apple needs to improve error handling in Mail so that it can distinguish between no response from the server and a response from the server indicating that the password is wrong. And it needs to give more appropriate advice to the user in its error messages when such situations occur.

I know very well that things can be flakey on the Internet and that the reliability of error reporting also depends on the reliability of the information provided by the servers, which is not always optimal. But I am also quite sure, based on past experience with Mail, that Apple hasn’t put nearly enough effort into making sure that such confusing situations are reduced to an absolute minimum. Surely if a server doesn’t respond at all the message/command received by Mail is not the same as when it responds by saying that the password is incorrect! If the server doesn’t respond, then the message is probably nothing, right? Since when does “nothing” mean “wrong password”?

One Response to “Apple Knowledge Base article on ‘server rejected password’ error message in Mail”

  1. Henry Neugass says:

    For what it is worth, I’ve been having some trouble with Entourage and one particular email server — probably overloaded — and I get what are probably similar errors transiently. Entourage doesn’t give very useful error messages. The MVPs recommended packet sniffing to discover the actual SMTP errors and recommended a couple of utilities.

    I’m not quite that desparate yet…

    It’s true, apps can give misleading or error messages. It’s a difficult problem, for sure. I guess if I had my ‘druthers I’d have a switch on each app to enable detailed error reporting to the system log.

Leave a Reply

Comments are closed.