配置 zend 使用 gmail smtp:Windows Apache 开发环境:“无法打开套接字”错误 - 反复 - 发疯
我的开发环境是 Win XP SP2 / Apache 2.something PHP 5.something_or_other
我的产品环境是 Linux Ubuntu / Apache 2.something_else PHP 5.something_or_other_else
代码全部是 Zend Framework 版本:1.11.1
我可以 telnet 到:smtp.gmail .com 465 来自 PC。
我在我的电脑上配置了 Mercury 以使用 gmail,因为它是 smtp 主机,并且工作得很好。 (MercuryC SMTP 客户端)。 Mercury 设置为在 smtp.gmail.com 上使用端口 465 和 SSL - 没问题。
Zend mail 在我的生产环境中使用生产邮件服务器发送邮件运行得很好。它的基本 application.ini 相同,但邮件变量的值不同。
在我的本地 PC 开发设置中,我的 application.ini 包含:(与我在 Mercury 中使用的值相同)
mail.templatePath = APPLICATION_PATH "/emails"
mail.sender.name = "myAccount"
mail.sender.email = "[email protected]"
mail.host = smtp.gmail.com
mail.smtp.auth = "login"
mail.smtp.username = "[email protected]"
mail.smtp.password = "myPassWord"
mail.smtp.ssl = "ssl"
mail.smtp.port = 465
我已经进行了数小时的试验和错误,试图获取一封电子邮件,但没有成功。在每种情况下,无论服务器或端口设置如何,它都会引发错误并报告:
Could not open socket.
Apache 和 Mercury Core 都是我的 Windows 防火墙配置中的例外。水星似乎没有问题。
在发布这篇文章之前,我已经在 stackoverflow 上进行了搜索,并且已经用谷歌搜索了几个小时——但没有成功。
我正在慢慢失去理智
,非常感谢任何有关可能出现问题的提示。
感谢您的阅读。
===================
顺便说一句,
当我在本地 PC 上使用与生产主机上相同的 application.ini 值时,我收到相同的“无法打开套接字”错误。
这些值是:
mail.templatePath = APPLICATION_PATH "/emails"
mail.sender.name = "otherUser"
mail.sender.email = "[email protected]"
mail.host = smtp.otherServer.com
mail.smtp.auth = "login"
mail.smtp.username = "[email protected]"
mail.smtp.password = "otherPAssWord"
mail.smtp.ssl = "ssl"
mail.smtp.port = 465
我知道这些在生产(Ubuntu)环境中工作。
我完全困惑了。
=================================================
看来在代码的内部,尝试连接写为:
$this->_socket = @stream_socket_client($remote, $errorNum, $errorStr, self::TIMEOUT_CONNECTION);
其中 $remote 的值为:
ssl:\/\/smtp.gmail.com:465
... 鉴于我当前版本中上面的 application.ini 值 - 根据错误我刚刚放入的消息检测。
由于它正在生产中运行,我相当怀疑其中存在问题。但是......以防万一它有帮助,就在那里。
事实上,对我来说这看起来很正常。
================================
它似乎失败了,错误号为 0 ——我理解这意味着有初始化套接字时出现某种问题。
==============================
为了理智起见,我刚刚检查了 php.ini 并确认两者:
extension=php_openssl.dll
extension=php_sockets.dll
... 均已启用。
My dev environment is Win XP SP2 / Apache 2.something PHP 5.something_or_other
My prod env is Linux Ubuntu / Apache 2.something_else PHP 5.something_or_other_else
The code is all Zend Framework Version: 1.11.1
I can telnet to: smtp.gmail.com 465 from the PC.
I have Mercury configured on my PC to use gmail as it's smtp host and it works just fine. (MercuryC SMTP Client). Mercury is set to use port 465 and SSL on smtp.gmail.com
-- No problem.
Zend mail works just fine on my production environment using the production mail server to send out mail. It's the same basic application.ini but with different values in the mail variables.
On my local PC dev setup, my application.ini contains: (same values as I use in Mercury)
mail.templatePath = APPLICATION_PATH "/emails"
mail.sender.name = "myAccount"
mail.sender.email = "[email protected]"
mail.host = smtp.gmail.com
mail.smtp.auth = "login"
mail.smtp.username = "[email protected]"
mail.smtp.password = "myPassWord"
mail.smtp.ssl = "ssl"
mail.smtp.port = 465
I have been doing trial and error for hours trying to get a single email out with no success. In every case, regardless of server or port settings it throws an error and reports:
Could not open socket.
Both Apache and Mercury Core are exceptions in my Windows Firewall config. Mercury seems to be having no problem.
I have searched stackoverflow before posting this and have been googling for hours -- with no success.
I am slowly losing my mind
I would be very much obliged for any tip as to what might be wrong.
Thanks for reading.
===================
BTW
When I use the SAME application.ini values on my local PC as on the production host, I get the same "Could not open socket" error.
Those values are:
mail.templatePath = APPLICATION_PATH "/emails"
mail.sender.name = "otherUser"
mail.sender.email = "[email protected]"
mail.host = smtp.otherServer.com
mail.smtp.auth = "login"
mail.smtp.username = "[email protected]"
mail.smtp.password = "otherPAssWord"
mail.smtp.ssl = "ssl"
mail.smtp.port = 465
I know these work in the production (Ubuntu) environment.
I'm utterly baffled.
===============================================
It seems that down in the guts of the code the attempt to connect is written as:
$this->_socket = @stream_socket_client($remote, $errorNum, $errorStr, self::TIMEOUT_CONNECTION);
where $remote has the value:
ssl:\/\/smtp.gmail.com:465
... given the application.ini values up above in my current version -- according to the error message instrumentation I just put in.
Since it's working in production I rather doubt that there is something wrong with that. But ... just in case it helps, there it is.
Actually it looks normal enough to me.
==============================
It seems to be failing with an error number of 0 -- which I understand to mean that there is some sort of problem initializing the socket.
==============================
Just for sanity's sake I just checked php.ini and confirmed that both:
extension=php_openssl.dll
extension=php_sockets.dll
... are enabled.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好的,伙计们。首先我想说,!#$#%$#$##@$$$!#!$ !!!!!!!!!!!!!!!!!!
说,表面背后隐藏着两个问题。我要把我身后的故事留给他们。
==================================
第 1 部分 为
我正在从事的 Zend 项目奠定基础的天才们,非常正确地在 application.ini 中设置了适当的邮件参数,如上所示。
他们在名为 Services 的网站子目录中设置了某种默认传输,并在名为 Mail.php 的文件中使用了 OurNameSpace_Service_Mail 的名称。 >。美好的。
然后他们继续在该类的内心深处说:
……因此忽略了他们小心翼翼地放入 application.ini 中的值。 太棒了!
一句警告。从 Zend/Mail/PROtocol/Abstract.php 发出的错误消息和
Zend/Http/Client/Adapter/Socket.php 不会公开太多有关错误的信息,因此我必须自己检测它们。当错误号为 0 时(就像我的情况一样),这会更烦人。
有人应该打电话给诺贝尔委员会并提名我的项目天才获得最佳编码实践奖!感谢 Zend 提供的无用错误消息。
==================================
第 2 部分
愿天堂的天使们将奖励洒在发布此网页的优秀人员的头上:
PHP Windows 安装:无法加载动态库 php_mssql.dll、php_pspell.dll 等< /a>
URL
http://www.undermyhat.org/blog/2009/07/php-windows-install-unable-to-load-dynamic-library-php_mssql-dll-php_pspell -dll-etc/
发生的事情是这样的。希望我的日志可能有一些东西,我在 Apache 的 error.log 中查看,并发现:
当然,这让我充满了喜悦和满足——特别是因为我知道 dll 已启用,并且当我检查时,它就在那里在 ext 目录中,就在它应该在的位置。苦难。
正如上面链接的页面所解释的,问题证明是缺少依赖项。
php_openssl.dll 依赖于 Apache 未找到合适版本的其他几个 dll。
当我将这些 dll 从 PHP 的根目录复制到 Apache 的 bin 目录时,问题就消失了。我不会在这里重复那个优秀的技术提示页面的内容。
再次,愿天堂的恩赐降临到整理出解决方案并发布它的技术人员身上。
================
快乐编码。
OK folks. First I'd like to say, !#$#%$#$##@$$$!#!$ !!!!!!!!!!!!!!!!
That said, there were two problems hiding behind the surface. I'm going to leave the story here for them what comes behind me.
================================
Part 1
The geniuses who built the foundations of the Zend project I'm working on, very properly set up the appropriate mail parameters in application.ini as shown above.
They set up a default transport of sorts in a subdirectory of the site they called Services, by the name of OurNameSpace_Service_Mail in a file called Mail.php. Fine.
They then proceeded, down in the guts of that class to say:
... thus ignoring the values they had carefully put into application.ini. Brilliant!
A word of warning. The error messages issuing from Zend/Mail/PRotocol/Abstract.php and
Zend/Http/Client/Adapter/Socket.php don't expose much information about errors, so I had to instrument them myself. This is even more annoying when the error number is 0 as it was in my case.
Somebody ought to call the Nobel committee and nominate my project brainiacs for a best coding practices award! And thanks, Zend, for the useless error messages.
================================
Part 2
May the angels of heaven shower rewards on the head of the excellent fellow who put up this web page:
PHP Windows install: Unable to load dynamic library php_mssql.dll, php_pspell.dll etc
URL
http://www.undermyhat.org/blog/2009/07/php-windows-install-unable-to-load-dynamic-library-php_mssql-dll-php_pspell-dll-etc/
What happened is this. In the hope that my logs might have something I looked in Apache's error.log, and found:
Of course this filled me with joy and satisfaction -- especially since I knew that the dll was enabled and, when I checked, it was right there in the ext directory, right where it should be. Misery.
As the page linked above explains, the problem turned out to be a missing dependency.
php_openssl.dll depends on a couple of other dll's that Apache was not finding the right versions for.
When I copied those dll's from PHP's root directory to Apache's bin directory, the problem went away. I wont repeat the contents of that excellent tech-tip page here.
Again, may the gifts of heaven fall on the techie that sorted out the solution and published it.
================
Happy coding.