Fsockopen Time-Out Issue With Gmail Smtp

[mtleng]

I'm having an issue using fsockopen to connect to smtp.gmail.com in which I always receive the error "Failed to connect to server: Connection timed out". The issue seems very similar to an old bug fixed in late 2010: https://bugs.php.net/bug.php?id=50953

 

I'm using the following script to test:

// connect to the smtp server
$smtp_conn = @fsockopen("ssl://smtp.gmail.com", // the host of the server
 465, // the port to use: 25, 465, 587
 $errno, // error number if any
 $errstr, // error message if any
 5); // give up after ? secs
// verify we connected properly
if(empty($smtp_conn)) {
$error = array("error" => "Failed to connect to server",
 "errno" => $errno,
 "errstr" => $errstr);
echo "SMTP -> ERROR: " . $error["error"] . ": $errstr ($errno)\n";
} else {
fclose($smtp_conn);
echo "Connected!\n";
}

 

Replacing the host argument with tsl://smtp.gmail.com or simply smtp.gmail.com and any combination of ports 25, 465, 587 also fails. Yet other smtps connect fine (e.g. smtp.live.com:587, smtp.mail.yahoo.com:465).

 

A firewall or other blocking is not the issue. This is on a VPS with the firewall disabled and, furthermore, I can successfully connect to smtp.gmail.com (and send an email) via openssl s_client. So basic access to the server/port is not the prob.

 

Is there any possibility this old bug (id=50953) is still lingering around in a fairly recent 5.3 version of PHP? Or any suggestions on other possible causes?

 

I am using 5.3.17-1~dotdeb.0 and same code works fine on a different VPS with PHP 5.2.17-1.

Edited October 20, 2012 by mtleng

[jazzman1]

Where do you execute the script - from a local machine or remote one ?

I've tested it from my local server and got a successfully message.

[mtleng]

Where do you execute the script - from a local machine or remote one ?

I've tested it from my local server and got a successfully message.

 

What version of PHP did you try on and on which distro? I'm running this on a remote Deb6 VPS. I'll try on a local VM with same PHP and see if it works.

[jazzman1]

Is it a shared hosting server?

[kicken]

Remove the @ before the fsockopen call so you can see any warnings that may be emitted. Does your PHP install have SSL enabled?

 

[jazzman1]

I'm thinking that your hosting provider it's blocking your ssl connection on port 465 to googlemail.com..

Why the same port works just fine to yahoo.com, I don't have an answer

[mtleng]

Ok, figured it out.

 

As I mentioned in the 1st post, there is no blocking. I can connect (auth, login, send email, etc) to smtp.gmail.com just fine with an alternative method (openssl s_client).

 

As far as I can tell, this IS the same bug I mentioned earlier. I tested on a local VM and the test script worked fine. So I strace'd the same php script on the VM and the VPS then diff'd the outputs. This revealed (excatly as described in PHP bug #50953) that the VPS was trying to connect via IPv6, timing out, then aborting (rather than trying IPv4 after). Didn't happen on my VM becuase IPv6 is not enabled so IPv4 is used directly.

 

If I replace smtp.gmail.com with an equivalent IPv4 address, the script works fine on the VPS because this eliminates any IPv6 address resolving. I then entirely disable IPv6 on the VPS (sysctl net.ipv6.conf.all.disable_ipv6=1) and the script now works fine with smtp.gmail.com.

 

I think I'll add a comment to the PHP bug to request it be re-investiaged.

[kicken]

Have you tried a higher timeout value? Perhaps it is hitting your timeout before it has a chance to get an error using IPv6, thus never trying IPv4.

 

I've tested on PHP 5.4 connecting to the host on two different machines and it worked fine. On my VPS it connected via ip6 since it is available. On my dedicated box it connected via ip4 since there is no ip6 network connectivity available (ip6 is enabled in the os, the network just does not support it).

 

[mtleng]

The short timeout is just for testing, the actual app (phpmailer) uses a much longer timeout and still fails. According to the bug report, however, fsockopen should never timeout at all in this case, rather the connection should be immediately refused and the tried again via IPv4.

 

Maybe this issue is specific to 5.3? Maybe even specific to my distro? Not really sure.

[kicken]

According to the bug report, however, fsockopen should never timeout at all in this case, rather the connection should be immediately refused and the tried again via IPv4.

 

I was thinking of the possibility that maybe somewhere down the network (the router or ISP) IPv6 traffic is dropped or mis-routed which would lead to a connection attempt just lingering for a while until something times it out, rather than it being refused. Do you know if your network actually supports IPv6?

 

Can you connect to something using IPv6 using another utility like wget or netcat?

[mtleng]

I was thinking of the possibility that maybe somewhere down the network (the router or ISP) IPv6 traffic is dropped or mis-routed which would lead to a connection attempt just lingering for a while until something times it out, rather than it being refused. Do you know if your network actually supports IPv6?

 

Can you connect to something using IPv6 using another utility like wget or netcat?

 

I see your point (and from what I've heard about IPv6 issues that sort of thing wouldn't be surprising). I wonder if openssl s_client works in the same manner? That is, attempts IPv6 then falls back to IPv4. If it does, then that would eliminate that possibiliity since I had no probs connecting in that manner. It's too late for me to check now. I've already disabled IPv6 on the VPS and moved on. Cannot go back and re-enable for testing at this point.

 

In anycase, disabling IPv6 on the VPS seems to be the solution to avoiding such issues (whether bug or network related). And since there's no need for IPv6 on the VPS at this point I so no reason to keep it around (...not in use, not open to abuse).