I recently encountered a bizarre problem with Mail.app, the email client included in Mac OS X, that took me quite a while to solve (with no help from AppleCare; more on that in a separate blog posting). I’m posting about the problem and its solution here so that, with any luck, the next person who stumbles upon it will be able to find this solution with a Web search.
The iMac in our house has several users on it. Each of them has Mail.app configured to talk to the same servers for incoming and outgoing mail, using essentially the same settings (aside from different usernames and passwords). One day, after Mail.app crashed several times in a row for one of the users, it suddenly stopped being able to send mail. Any attempt to send a message yielded this:
(For search engines, here’s the text in the error pop-up:
Cannot send message using the server server
The server “server” refused to allow a connection on the default ports.
Select a different outgoing mail server from the list below or click Try Later to leave the message in your Outbox until it can be sent.
Sending from: Jonathan Kamens <jik@kamens.us>
[Edit SMTP Server List]
[Connection Doctor]
[?] [Edit Message] [Try Later] [Try With Selected Server])
I knew there was nothing wrong with the server. I run it myself, so I was able to check that the SMTP daemon was running and accepting connections. Furthermore, I was able to confirm that right before the error above occurred, Mail.app was connecting to the SMTP daemon. In addition, as noted above, sending mail was working for this user right before Mail.app crashed several times, and furthermore, sending mail was working for all the other users on the computer.
To debug this further, I clicked on the [Connection Doctor] button, told the Connection Doctor to display the details of its tests, and then told it to run the test again. In the resulting transcript, I could clearly see Mail.app connecting to the SMTP server, so at first glance it was not clear why it was claiming that it couldn’t. However, upon further examination, it was clear that something was wrong.
When an SMTP client connects to an SMTP server, the first thing it does is send the command “EHLO client.host.name“. The “EHLO” command indicates a request to start an Enhanced SMTP session (“Enhanced SMTP HeLlO“), and “client.host.name” is supposed to be the fully qualified host name of the client. If the server rejects the EHLO command, then the client sends “HELO client.host.name” instead. The “HELO” command represents a request to start a regular (i.e., not enhanced) SMTP session. Both commands are necessary because some SMTP servers don’t support Enhanced SMTP.
I could clearly see attempts by the client to send both EHLO and HELO commands to the SMTP server. I could also clearly see that for some reason the server was rejecting both commands. Closer examination revealed why. For some reason, the client.host.name sent by the client to the server had two spurious question marks in it before and after the first period in the host name. That is, instead of sending client.host.name, it was sending client?.?host.name. The server was correctly rejecting the commands from the client, because question marks are not valid characters in host names. Bizarre!
I suspected that something in Mail.app’s settings must have gotten corrupted when it crashed several times in a row, so I tried shutting down the app, Library/Preferences/com.apple.mail.plist, and restarting. It didn’t help. I tried removing all of Library/Caches. That didn’t help either. In desperation I tried removing all of Library/Preferences, and even that didn’t solve the problem (note for the latter two attempts, I had to log out the user and remove the files as root).
Finally, in what turned out to be a moment of inspiration, I shut down the app and removed several hidden files and directories from the user’s home directory:
rm -rf .CFUserTextEncoding .DS_Store .bash_history .cups .ssh
Lo and behold, when I restarted Mail.app after removing these files, sending mail was working again.
It’s hard to say for certain which of these files was the culprit, but I’m pretty sure it was either .CFUserTextEncoding or .DS_Store.
I don’t know if anyone else is ever again going to encounter this problem, but if so, then now you know how to solve it. If you do encounter it and this solution works for you, please leave a comment and let me know!
My Mail app did this today and I’ve spent hours trying to fix it. Not only did it it stop sending E-mails to the servers but your instructions don’t fix it. Also changing the port for connecting to the SMTP server causes Mail to loose all of my mail and I have to restore an old copy it from username->library->mail and restart Mail and rebuild Mail to fix it. This is the second time it did this recently and I’ ready to find a different E-mail program.
Thank you! I was having this problem with a hotmail account. Emails were actually sending but they weren’t being taken out of the outbox and marked as sent. Was getting the”Can’t send message using this server” error even though the emails were sending. Deleting the files you suggested and restarting Mail solved this problem. Thank you!
see hidden files with the command:
ls -la
Helped me as well to delete those files. Thanks!
… and finally… almost certain it’s those .DS_Store, which now that
I have used onyx to “unhide” things in my finder are everywhere…
go to and look at some of this…
http://www.google.com/search?client=safari&rls=en&q=mac+what+does+.DS_Store+do&ie=UTF-8&oe=UTF-8
I haven’t read any of these yet and it may stretch my computer
cmprehension as I don’t even know how to
use terminal but…
should have been clearer..
talking about CFUserTextEncoding or .DS_Store.
I trashed both and believe it was latter…which kept rebuilding so I trashed
for a fourth time and intuitively beat the rebuild by shutting down…
wasted an hour w/verizon then thought to google question and found this blog…
thanks a million …. used onyx to see hidden files and trashed 4x’s and shutdown and started and my outgoing subaccount is back.
my problem was my main mail account and two other sub accounts were all fine..
one sub account would receive incoming but kept asking me for password for out going for that account and then reject the correct password. on reboot didn’t even ask for password …. must have reset from keychain…thanks again very much…. i can go to sleep a happy peaceful man :-)))
Thanks, had exactly this problem. Applied the above “therapy” and despite not being able to locate 1-2 files I deleted the rest and lo and behold the send mail functionality of mail.app (rather essential in an email programme) was restored. I don’t know what these files do, I presume the app rebuilds these as needed. Could not find any similar advice on Apple support.
I had three eMails hanging in the Outbox while getting the sporadic ‘Cannot send message using this server ***’
I did not find the following files in my home directory: rm -rf .CFUserTextEncoding
but I did delete the others, one by one, always shutting down Mail in between. After deleting .ssh one file went out, the others are still waiting. They always go out eventually.
Stephen, above, explains quite detailed how to show hidden files using the Terminal. I use a little tool called “Blind” (Google for it) that does the same thing with one click to unhide and one click to hide again.
Thanks, Had exactly the same problem. Your solution worked immediately.
Hans Rwenkema
From the terminal, you can show hidden files right in your regular desktop (on the Mac, starting a file name with a period (dot) makes the file hidden. But sometimes we really do need to see these files!)
Launch the Terminal and enter the following commands–and really, the computer is pretty literal, so EXACTLY as you see them here. Copy and paste if possible! This command makes the Mac show up all the hidden files–you’ll be amazed:
defaults write com.apple.Finder AppleShowAllFiles TRUE
Now you must relaunch the Finder by killing it, so the Mac knows to change to the new procedure:
killall Finder
Note: when you are executing commands in Terminal (lovingly called “The Command Line”) you type (or paste) in the command, then hit your “return” key to command the Mac: Do this now! But the command line just jumps the cursor down to the next line, ready for another command–it often doesn’t tell you “OK, that worked, what’s next, Oh my Master?” If the command fails, though, you do usually get some kind of error message.
If you want to hide those pesky hidden files again–they were hidden in the first place so you wouldn’t accidentally delete them, making your Mac do very strange things, and perhaps not starting at all–type the following at the Terminal prompt:
defaults write com.apple.Finder AppleShowAllFiles FALSE
And yes, to “Make it Happen” you’ll need to do the restart the Finder command:
killall Finder
Steve Carter
“…a moment of inspiration, I shut down the app and removed several hidden files and directories from the user’s home directory:
rm -rf .CFUserTextEncoding .DS_Store .bash_history .cups .ssh”
I’m afraid, that’s arkana to me — how & where do I find these? When walked thru, I dare going into Console and Terminal but as I say: ARKANA. Easiest way out by now to my mind: drop mail.app, it caused send problems time and again.
Many thanks, if you do feel like answering and aged user (first Mac bought Jan. 1988) of a ‘computer for the rest of us’.
Reinhard
Sorry, those are hidden files, and I don’t know any way to get the Mac Finder to show hidden files, so the only way I know of to delete these files is in a terminal window as I’ve shown.
Pingback: Apple Support disappoints « Something better to do