Apple Mail phones home too
Not long ago Daniel Jalkut discovered that Dashboard calls home 
to Apple to check for widget updates. Today I discovered that Mail.app does the same thing.
Recently at my real work but not at home, Mail has been hanging for 30 seconds to a minute each time I tried to reply to an email. I would hit the Reply button and have time to make a cup of coffee in the kitchenette before the reply window appeared.
Luckily, the network administrator at the College, Tim Bell, has god-like tcpdump powers. He uncovered what was happening.
Each time I reply to a message, Mail attempts to contact an Apple server through port 80. That’s not a problem at home, but it is at work, where port 80 is blocked and a proxy redirects all HTTP traffic through another port. Mail didn’t respect my proxy settings. It carried on regardless with a process that eventually failed after lengthy delay.
Tim opened the port so that we could see what Mail was trying to do.
Mail was sending the following request based on my .Mac username to certinfo.mac.com (17.250.248.148):
GET /lookup?timgaden HTTP/1.1
In response, it was getting:
================
R5IGFzc3VtZXMg
YWNjZXB0YW5jZSB
The third line in base64 decodes to G\x92\x06\x1777V\xd6W2 (where \x?? means the non-ascii character 92 (in hex), etc.) – so Tim tells me – and the fourth line to acceptance (with a trailing space).
Once we understood the problem, we could google for an answer. It turns out that Jonathan Wight experienced the same thing a year ago. He also provides a fix: delete the ~/Library/Preferences/com.apple.security.plist preferences file.
I’m not suggesting that anything nefarious or underhand is happening here, but it still puzzles me on three fronts.
First, what exactly is it checking and what is the undecipherable response? Is it checking my iChat certificate?
Secondly, why should Mail try to do this when I am replying to a message in my work account on my work server?
Thirdly, why is Mail so stupid? What design oversight makes it overlook my system-wide proxy settings and carry on banging away at port 80, giving me endless delays? Normally, Mail.app helps me to get things done, but not here.
UPDATE: MacGeekery has posted an interesting take on this, which is worth a read.
I hope I made it clear in my post above – although perhaps I didn’t – that I do not think Apple is stealing my credit card information or looking for cracked software or turning my computer into a drone for Apple press releases or doing anything else untoward.
I do think it is puzzling that my proxy settings were ignored and that Mail.app was thus unusable for up to a minute everytime I tried to reply to a message. I do think it is puzzling that the fix was so hard to find. I do think it is fair to expect better of Apple than this.
[Thanks for your help this afternoon, Tim. All my tcpdump are belong to you.]
Similar Posts:
- Long delays with Mail.app replies
- Posting .Mac mail when Port 25 is blocked
- Emailing from Starbucks: What port 587 is for
- Three outgoing mail fixes for Mac users on the go
- Four things that Mail.app can’t do
Tags: Apple Mail, bug, certificates, hanging, mail.app, port 80, proxy, reply, security, spinning beachball of death
July 19th, 2006 at 12:35 am
A little disturbing. I hope this turns out to be nothing but I also hope this doesn’t start becoming a trend for Apple.
July 19th, 2006 at 1:07 am
Seems like a built in assumption that if you have a .Mac account, you are probably using a .Mac email address and iChat.
July 19th, 2006 at 1:56 am
I don’t think you want to necessarily dump com.apple.security.plist. Mine references the main keychain database in ~/Library/Keychains and the AlmostVPN keychain. Maybe you had a reference to a .mac account which was not valid or unused in Mail preferences and it was just checking authorization data for the account.
July 19th, 2006 at 2:20 am
Chances are this is checking with .mac or with ichat for presence. If you do this again and while it is stalling out, open activity monitor and do a sample of Mail, I could probably figure out what it is trying to do.
July 19th, 2006 at 2:21 am
I’m curious; does Mail.app do this when the user does not have a .Mac account?
July 19th, 2006 at 2:23 am
.mac mail is pretty unusual because it will allow a mail client (as opposed to webmail) to send mail through an smtp server not on your current domain. The non-paranoid among us might suspect this a security handshake designed to help prevent spoofing or other abuse that might lead to .mac being put on global spammer lists or other such horrors.
July 19th, 2006 at 2:49 am
I think this is Mail.app checking certificate validity. Perhaps have a .Mac certificate for signing mail and secure iChat? In my case, the lookup?mydotmacusername URL returns my certificate in a base64 encoded form.
Do you have Search .Mac for Certificates checked in Keychain Access prefs? And do you have OCSP or CRL turned to anything but off in the Certificates tab of Keychain Access prefs?
July 19th, 2006 at 2:58 am
Interesting stuff!
Seems Apple have their own certificate authority hiding behind the scenes…
Doing a lookup for a ficticious user gives,
fuef3uewfwf
===========================
No certificates found.
===========================
However using a friend’s .mac account ID,
XXXXXXXX (changed to save his innocence!)
===========================
—–BEGIN CERTIFICATE—–
MIIFIDCCBAigAwIBAgIDEW0YMA0GCSqGSIb3DQEBBQUAMIGGMQswCQYDVQQGEwJV
UzEdMBsGA1UEChMUQXBwbGUgQ29tcHV0ZXIsIEluYy4xLTArBgNVBAsTJE
The whole of the certificate then follows. One can then save this file as a ‘.cer’ file – double click that and Keychain will load it in…
I think your friend was not capturing the whole packet – use ‘-s 1500′ to capture the whole lot – and so you only saw parts of the result.
BTW: a lookup for ‘steve’ returns no results ;-)
So, with this, when a mail comes in that purports to be from a .mac user, your mac can go to apple. ask for the cert for the user and then use that to check if the email really is from them…
Apple intending on doing something about spam??
aid
July 19th, 2006 at 4:47 am
it’s actually not even “behind the scenes” nor is it “phoning home.”
part of the .Mac service is a public certificate server, though you don’t have to have a .Mac account to use it, nor do you need one to see this behavior.
It’s part of the newest .Mac SDK and any developer can use it. You can disable this in Keychain Access by going into Preferences and deselecting “Search .Mac for Certificates”.
July 19th, 2006 at 4:58 am
Nice post JC.
July 19th, 2006 at 5:03 am
Yes, it’s just a cert-check – and it’s not directly related to sending mail via your non-.Mac accounts, but rather polling upon send, is my guess.
I’ve a .Mac account and don’t see this behavior, using my own outbound SMTP server, FWIW.
July 19th, 2006 at 5:09 am
Also, don’t forget mail icons. As far as I remember, old versions of Mail.app used to lookup .Mac usernames and download a contact icon…
July 19th, 2006 at 5:29 am
Actually Address Book “phones home” too because it does something similar to what you describe anytime you look at a contact with a .mac address. I have a feeling that iChat probably does this too. Like Rui said it’s probably just getting the contact’s icon info as you probably don’t need a cert check for your address book or iChat. But the paranoid part of me wonders if anything else is going on.
July 19th, 2006 at 8:31 am
I think a good point here is “Hawk Wings” has put out a load of crap-again. He’s always been suspicious to me anyway….get your ducks in a row, Mr. Wing!
July 19th, 2006 at 8:40 am
Stepping back for a second, I think it’s interesting that the customer view of Apple is changing from blind fanaticism to blind paranoia. I tend to be in the middle. I know some of Apple’s practices hurt its users, while sometimes the press and blogosphere sensationalize half-truths. Is it that Apple is becoming more like Microsoft or are we users just getting more jaded?
July 19th, 2006 at 8:51 am
For me it’s primarily a usability issue. I am not interested in the “Evil Empire” angle, but I am interested in Apple’s “It just works” philosophy.
Here that philosophy gets undermined. I am not as smart about these things as Scott, Rui, JC, Adrian and (obviously) Alan are, but I am not clueless either.
There is no way that I could have debugged this problen without Tim’s help and the help of a handful of others who are “in the know”. I would have faced this 30 second to one minute delay in using Mail in perpetuity.
That simply seems like bad usability design to me, something for which Apple is otherwise justly famous.
Nor do I really understand why Mail ignored my proxy settings and didn’t route the request through the proxied port, which would have prevented the problem arising in the first place.
July 19th, 2006 at 9:00 am
I understand completely. It would also bug me if I had to wait a minute or more before I could reply to an e-mail. “Hmmm..” he wonders to himself, “I have a pause between the command-r and the new message window popping up, do I want to fix it?”
I wonder, are there any repercussions to deleting the com.apple.security.plist file besides getting rid of that cert lookup issue? I’m hesitant to delete an Apple plist that has the word ‘security’ in it.
July 19th, 2006 at 9:29 am
@Miles, JC – Thanks for the more elegant fix. That does seem to be it.
@Adrian – That would make sense to me if the email I was replying to had come from a .Mac account or if I was using a .Mac account to reply to it. But I was using my work account to reply to any email sent from another user at work.
@Dave – I don’t know enough to have an opinion :) But unchecking the option in Keychain’s preferences seems preferable. I can’t test until I am in at work tomorrow, but checking it is what creates the com.apple.security.plist file in the first place. So it looks promising.
July 19th, 2006 at 9:46 am
Tim,
Mac Geekery responds to this or clarifies this misunderstanding. Worth a look if you haven’t seen it.
http://www.macgeekery.com/tips/mail_app_doesnt_phone_home_either
July 19th, 2006 at 10:07 am
John, thanks for the link. That definition of “phoning home” is interesting and useful. I should watch my language more carefully.
But the post seems to assume that my concern is of a tin-foil hat conspiracy nature. I hope it make it plain in my post that this is not the case.
I am more concerned about Mail not obeying my proxy settings and thus rendering itself unusable for over a minute everytime I tried to reply to a message. And about the difficulty of finding a fix for the problem.
July 19th, 2006 at 10:34 am
Did deleting the plist file fix the proxy issue?
July 19th, 2006 at 10:52 am
Yes, it did.
October 18th, 2006 at 11:12 pm
[...] I won’t repeat it all here, but you can read the whole saga in “Apple Mail phones home too”. [...]
October 19th, 2006 at 11:11 pm
it says to disable checking .mac for certificates but on both my Macs it’s disabled by default
January 9th, 2007 at 6:48 pm
I just started having this problem. I don’t have a .mac account, and .mac cert checking was disabled.
I did have OCSP and CRL (in the certificates pane of the Keychain Access preferences) both set to “Best Attempt”. Turning these both off made the delays stop.
It seems the OCSP server (revealed in the cert details) for my email cert is unreachable at the moment.
I turned this back on, opened the Mail Activity Viewer window, and hit the new message button. It hangs of course, but there’s no clue in the activity viewer what it’s doing. It would be nice to have a hint there like “Checking user@host cert: waiting for ocsp.ca.org”.