Unable to verify $_POST vars.

We have recently installed S2Member on out test site to determine whether it will be suitable to manage the subscriptions to our daily newsletter. If all goes well we will eventually buy a licence as we need to migrate out 7000+ readership to S2Member.

The system is setup to have a trial period after which the user will be billed for their yearly subscription. For test purposes we have set the trial to 1 day.
Currently after the person hits subscribe they are sent to paypal after completing the paypal they are redirected back to the site where they are told to wait up to 15 minutes for the email to come through.
After 15 minutes no email arrives and the new subscriber is not listed in the members list. Though their Paypal recurring payment has been set up correctly.
We have loaded and run s2member-server-check with no errors or issues detected.
We have turned on debug and saw the Unable to verify $_POST vars message in the paypal-ipn.log. Here is the complete log.

PHP v5.3.16 :: WordPress® v3.4.2 :: s2Member® v121023
Memory 27.48 MB :: Real Memory 27.75 MB :: Peak Memory 27.53 MB :: Real Peak Memory 27.75 MB
new.traveldaily.com.au/?s2member_paypal_notify=1
User-Agent: 
array (
  's2member_log' => 
  array (
    0 => 'Unable to verify $_POST vars. This is most likely related to an invalid configuration of s2Member, or a problem with server compatibility.',
    1 => 'If you're absolutely SURE that your configuration is valid, you may want to run some tests on your server, just to be sure $_POST variables are populated, and that your server is able to connect/communicate with your Payment Gateway over an HTTPS connection.',
    2 => 's2Member uses the `WP_Http` class for remote connections; which will try to use `cURL` first, and then fall back on the `FOPEN` method when `cURL` is not available. On a Windows® server, you may have to disable your `cURL` extension; and instead, set `allow_url_fopen = yes` in your php.ini file. The `cURL` extension (usually) does NOT support SSL connections on a Windows® server.',
    3 => 'Please see this thread: `http://www.s2member.com/forums/topic/ideal-server-configuration-for-s2member/` for details regarding the ideal server configuration for s2Member.',
    4 => 'array (
  's2member_paypal_notify' => '1',
  'txn_type' => 'subscr_signup',
  'subscr_id' => xxxxxxxxxx',
  'last_name' => 'Piper',
  'option_selection1' => 'new.traveldaily.com.au',
  'option_selection2' => 'xxxxxxxxx',
  'residence_country' => 'AU',
  'mc_currency' => 'AUD',
  'item_name' => 'Student - for people studying tourism or hospitality. Cost $66 per year (inc GST) / description and pricing details here.',
  'business' => 'xxxxx@gmail.com',
  'recurring' => '1',
  'verify_sign' => 'xxxxxxxxxxxxxxxx',
  'payer_status' => 'verified',
  'payer_email' => 'xxxxxx@traveldaily.com.au',
  'first_name' => 'Bruce',
  'receiver_email' => 'xxxxxxx@gmail.com',
  'payer_id' => 'xxxxxxxxxxxx',
  'option_name1' => 'Originating Domain',
  'invoice' => '50b6e64810bb3~115.64.15.202',
  'option_name2' => 'Customer IP Address',
  'reattempt' => '1',
  'item_number' => '1',
  'subscr_date' => '20:36:42 Nov 28, 2012 PST',
  'custom' => 'new.traveldaily.com.au',
  'charset' => 'windows-1252',
  'notify_version' => '3.7',
  'period1' => '1 D',
  'mc_amount1' => '0.00',
  'period3' => '1 Y',
  'mc_amount3' => '66.00',
  'ipn_track_id' => 'a42ef065b9973',
)',
  ),
)

Any ideas advice would be appreciated.

As no one was able to help me, I decided to analyse the code myself. The above data looks like it should be OK so it seemed odd that there was this issue.
What happens when S2 member gets the IPN message from paypal is it has to send back the message it received to paypal at which point if everything is OK, Paypal will send back verified. When S2 member sends the message for verification it uses an HTTPS request which uses port 443. If port 443 happens to be blocked nothing goes out no error is returned and the code falls through to an else in c_ws_plugin__s2member_paypal_notify_in:paypal_notify() in paypal-notify-in.inc.php and the above error is logged.
My issue was simply fixed by opening port 443.
Curiously the server check function which they get you to run does not actually verify it can make an https request. Hence you think everything is fine after you run the test.

Hey, how did you open the port 443? I have the same issue…and this is hurting my business. Can u please help?

I am guessing on most hosting providers port 443 should be open. In our case all ports other than HTTP and a couple of others were closed due to a conserted attack on our site. In any case you should be able to log a ticket with your hosting provider to ask them to open the port for you.

Let me know how you go.