There are multiple sorts of push notifications around. In recent times, Apple wants folks to use APNs.
AFAIK, iOS devices do not reliably support IMAP push across cellular networks, and never have. APNs push notifications do work across various networks, and are supported by iOS. (I haven't tested mail APNs within Mavericks, however.)
There's also the IMAP push notifications, and Exchange ActiveSync and a few other schemes.
In general, iOS push notifications uses APNs and Exchange ActiveSync.
Apple provides APNs troubleshooting info, as well.
Most of the OS X Server push notification support is based on APNs. Not much uses IMAP push, though local desktop clients can still be configured use it.
FWIW, it's "APNs" with the capitalization that's commonly (and confusingly) used by Apple in various documents, and it's the Apple Push Notification service as was mentioned earlier.
i figured it out: profile manager was only half the truth. the other half were closed ports on the server.
i found this discussion: https://discussions.apple.com/message/22452856#22452856
there you can find this:
The solution was to open following ports:
o use Profile Manager, you should ensure that the following ports are open on your network.
Port TCP/UDP Description 2195, 2196 TCP Used by Profile Manager to send push notifications 5223 TCP Used to maintain a persistent connection to APNs and receive push notifications 80/443 TCP Provides access to the web interface for Profile Manager admin 1640 TCP Enrollment access to the Certificate Authority
once i opened 2195, 2196 and 5223 it started to work. you have to re-enter the info of the account but once you do it works like a charm.
ps: the interesting part is that once you switch on profile manager the ports 80, 443 and 1640 are opened automatically. when you enable push notification nothing happens which is stupid and should be updated in mac os x server maverick in the future - it should be a combination of: if you enable on push notifications, the ports are opened and you are prompted to start profile manager. let's just hope someone at apple reads these discussions...
I tried this and it still didn't work. I was sceptical it would work because the wording suggests that those ports are outbound, ie the apsd deamon process making outbound connections to Apple servers, not inbound connections from their servers to yours. I believe Profile Manager is correctly opening only the required inbound connections for you.
I did notice that my device enrollment looked a bit wrong. I was given the option to enroll my iPhone, while below that showing my iPhone already enrolled. So I removed the enrolled one, and re-enrolled. I then I removed those ports and followed another piece of advice - disable Push notifications and re-enable it. When I did, I went back to my iPhone and noticed that neither Fetch nor Manual were checked for the mail accounts. So I closed the settings app, re-opened it and voila! I have Push mail on iOS 7.0.3 from OS X Mavericks!
If you run this command:
sudo lsof -i -P | grep -i "5223"
You should see that the connection is "ESTABLISHED", that is your servers apsd process connection to Apples servers. If you don't see this, then yes - you probably are being resricted from making connections which would need some firewall rule changes. AFAIK, this is outbound - you connect to 5223, not the other way around, so you don't need to open them inbound which is why adding the Profile Manager service doesn't open them.
a) the list of ports clearly speaks of "send" and "receive" push notifications - yes, those might be with the apple servers but wouldn't the os x server communicate with the device on the same ports?
b) profile manager opening the required inbound connections might be fine, but - and that might have been an ommission in my explanation - they were not automatically opened on my firewall which resides on my airport
c) i never enrolled my iphone with profile manager and it still worked. only started profile manager, opened the ports on my firewall and it worked.
clearly I'm not nearly as knowledgeable as you are and you might be absolutely right about your assessment.
for me it worked by opening these ports on my firewall. :-)
Haha - I wouldn't say I'm more knowledgeable - you seem just as clued up, I'm just adding my experience in to the mix in the hope that someone might be able to set matters straight!
I see what you mean about the wording around "send" and " receive", it does make it sound like data is sent on one port and received on another, but I don't believe that is the case. Your machine has to have a connection established to a service on one of Apples servers in order to send messages back and forth - but someone has to initiate that connection first. The question is who initiates that connection? Does Apple's servers come to you to connect, or do you go to them? When a process wants to establish a connection with another process running on another machine it needs to know where that machine is (the IP address), and of all the services running on that machine, how to connect to the right one, this is designated by the port.
So if Apple connected to you, they'd need to know your IP address or hostname and try to connect to you when your machine was up and running. But that wouldn't be feasible, so it's up to you to connect to them. Software running on your machine will connect to one of Apples servers on a well known port to establish the connection.
When services on your machine creates a connection, it too is designated a port by the OS to communicate on (the local port) and then attempt to connect to the remote service on a given port. Now for security reasons you don't want anyone trying to randomly connect to ports opened by processes on your machine, so your airport will likely be blocking all inbound connections, but it's unlikely it'll be blocking you from making outbound connections. For example, you wouldn't be able to view websites unless ports 80 (and 443 for https) were explicitly opened by your airport. It's generally the case that all outbound connections are permitted - it's the inbound ones you don't want!
So, as Profile Manager can send push notifications in order to remotely update profiles on other devices, it needs to make a connection to Apples push service for profile update notifications on ports 2195 and 2196. I'm assuming that this service is used to notify devices of profile updates and sends back the status of the update to Profile Manager running on your server. So you can both send and recieve data on ports 2195 and 2196 once your machine has established the connection.
Now there appears to be another push notification service which is not specific to Profile Manager on port 5223. I'm guessing this is the one that Mail uses (and probably other services too) to notify devices that a new mail has arrived. Traffic would indeed flow both ways - send and receive - but again, you would be initiating the connection to Apple, so unless your airport is setup to deny outbound connections, then you would not need to open this port. Doing so would mean that the outside world can connect to port 5223 on your machine. It's unlike any process on your machine would be using that port, but it does open up your internal network to the world a little more.
If I run this:
netstat -f inet -p tcp
I get something like this:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 server.domain.com 49198 18.104.22.168.5223 ESTABLISHED
tcp4 0 0 server.domain.com 49317 22.214.171.124.2195 ESTABLISHED
This shows that a process on my server has a connection from port 49198 to the remote port 5223 on Apple's, and from local port 49317 to remote port 2195 on Apple's. Both connect TO Apple. No processes are listening on 5223, 2195 or 2196 on my server for Apple to connect in to my network. You can see those ports reside on Apples end, not mine.
I'm just wondering it either your airport is oddly set up to block outbound connections which you have opened, so opening outbound connections fixed it, or something else got fixed at the same time you opened those inbound ports. It would be interested to see if closing them again has any negative effect on your push service.
Ok, so I've learned something there - you don't even need to reroll a device to have this work! Cool!
I hope this has helped!