12 Replies Latest reply: Nov 11, 2013 3:17 PM by Paul Verity
joerg Level 1 Level 1 (25 points)

i'm going crazy here...

 

can anyone confirm or refute...?

 

my setup:

 

mac mini with os x server (mavericks) with imap mail server running, push notifications setup and certifications in place - works like a charm on all devices and via webmail (roundcube)

 

iphone/ipad/ipod (iOS 7.0.3): imap mail setup with access to all mails and folders but i cannot select push (only fetch or manual) at "fetch new data" in the settings.

 

now: i am 100% sure this same setup worked before with os x server (lion AND mountain lion) and iOS 6. i know it for certain because i forgot to renew my certifications last august and of course it stopped working. once i renewed my certs with apple (via os x server) it worked again flawlessly... until either mavericks or iOS 7?!?

 

has apple dropped the ball here (if so, big shame on you) or what am I doing wrong?

 

help please!!!!

  • 1. Re: iOS 7 imap push with mac os x server
    carbunkel Level 1 Level 1 (0 points)

    Same, push was working with calendar and mail on Mountain Lion Server, now with Mavericks the iOS devices no longer get push email. Calendars still seem to be pushing.

  • 2. Re: iOS 7 imap push with mac os x server
    joerg Level 1 Level 1 (25 points)

    thanks.

     

    now the question is: bug or "feature"?

  • 3. Re: iOS 7 imap push with mac os x server
    MrHoffman Level 6 Level 6 (12,470 points)

    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.)

  • 4. Re: iOS 7 imap push with mac os x server
    alexrmc92 Level 1 Level 1 (60 points)

    To push mail and other items to iOS devices you have to have push notifications enabled and i think profile manager as well. The iOS devices have to registered with profile manager and then will pull the push certificate and get notifications.

  • 5. Re: iOS 7 imap push with mac os x server
    joerg Level 1 Level 1 (25 points)

    Now that's very interesting and could make sense.

    Currently i do NOT have profile manager switched on but that might be what's needed.

     

    I will test this today and get back to you.

  • 6. Re: iOS 7 imap push with mac os x server
    joerg Level 1 Level 1 (25 points)

    not sure what you mean by APN?

  • 7. Re: iOS 7 imap push with mac os x server
    alexrmc92 Level 1 Level 1 (60 points)

    APN = Apple Push Notifications.

     

    This is what the Push Notificication feature of the Server app does.

  • 8. Re: iOS 7 imap push with mac os x server
    MrHoffman Level 6 Level 6 (12,470 points)

    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. 

  • 9. Re: iOS 7 imap push with mac os x server
    joerg Level 1 Level 1 (25 points)

    well, well...

     

    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.

     

    PortTCP/UDPDescription
    2195, 2196TCPUsed by Profile Manager to send push notifications
    5223TCPUsed to maintain a persistent connection to APNs and receive push notifications
    80/443TCPProvides access to the web interface for Profile Manager admin
    1640TCPEnrollment 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.

     

    finally...

     

    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...

  • 10. Re: iOS 7 imap push with mac os x server
    Paul Verity Level 1 Level 1 (15 points)

    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.

  • 11. Re: iOS 7 imap push with mac os x server
    joerg Level 1 Level 1 (25 points)

    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. :-)

  • 12. Re: iOS 7 imap push with mac os x server
    Paul Verity Level 1 Level 1 (15 points)

    Hi joerg,

     

    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 17.149.32.78.5223      ESTABLISHED

    tcp4       0      0  server.domain.com 49317 17.149.35.167.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!

     

    Paul