smtpauth and PHP Version: 5.2.17 (Zend: 2.2.0) issues

I have been trying to resolve intermittent problems with the smtpauth email feature from zen 1.5.1 on PHP Version: 5.2.17 (Zend: 2.2.0) Server OS: Linux 2.6.18-194.26.1.el5

I've configured email settings in admin in various combinations of email address FROM and SMTP the same or different to test it out but non works consistently. It can work for days until I discover that I can't sent emails through zen when I update order status. Same if I use the internal email feature via admin. To make emails go out I switch to PHP send method for a day or so, then I go back to smtpauth and it works again. Chasing ghosts! My hosting company is trying to asssist but they can't find anything in the logs and monitoring tools. They suspect an incompatibility of Zen and PHP version. See answer from them further below. Please let me know if this has been reported before?

Setting example and error:
Email Address (sent FROM) [email protected]
SMTP Email Account Mailbox [email protected]
Error ERROR: Failed sending email to: "name" with subject: "Order Update #1" The following From address failed: [email protected]

Host answer:

We went and re-looked this over and still the same results. dovecot (/usr/sbin/dovecot) running with PID 2886 (pidfile check method) came back successfully without issues. That said, we believe the versions of PHP and 1.5.1 are conflicting together and is the reason for issues. That said, another website we maintain which is owned by the Operations Manager was moved to this server for personal testing and that website also did not show what your explaining, even though once or twice it would not send but for the last 2 hours no problems have shown up.. Even though webmail and email clients are not problematic this is not from the server that is causing this issue. It is directly on ZenCart code that is causing the issue.

As using PHP for email method. It is not a major security risk but what is major risk is that your domain or email accounts risk highly getting blocked by email providers due to the PHP method does not send out proper headers. the RWL (Realtime Whitelist validation) would not be passed to the email carrier like yahoo.com, live.com etc. As a legit email and it would be sent in a format where it looks like spam. There is no domain validation for PHP mail.

At this current time we believe it is the conflict between ZenCart code and php version that is conflicting not the actual server itself as the server it self does not show any failures with SMTP when directly connected from the server.

I cannot find the link to the SMTP patch but here is a few others that were reported. https://www.google.com/#q=Creating+default+object+from+empty+value+in+authorizenet_aim.php+on+line+439
End Host answer.

Ok, so what is the cause of this behavior? All was tested with an out of the box zen install with no mods as my host first suggested the cause was some kind of mod in my live shops causing this strange behavior. That is now ruled out. Again, this all works fine for a few days then suddenly stops working and without any changes will work again later.

Can't say I've ever seen any problem like that with 1.5.1, even on newer PHP versions.

In v1.5.2 the emailing code was changed, so perhaps upgrading to the 152beta may be a useful test, even if you try it in a separate folder+database as a test site?

mydanilo:

Again, this all works fine for a few days then suddenly stops working and without any changes will work again later.

Dunno if it's of any help.
This sounds like the work of an over reactive IDS (Intrusion Detection System). One possible cause being too many emails being sent within a given timeframe.

Cheers
RodG

Well thank you for the responses. Yes, I can definitely install a 1.5.2 as well and hopefully test when it next happens. The thing is that I am hesitant leaving it set to smtpauth as the final order step seem to hang for a long time whenever the problem exist. Don't want to loose any orders. But how else to solve?

So I am wondering if my host would see if an over reactive IDS is the cause in some log? They say they monitor my sites now 24/7. No result. Nothing in my error logs ether.

I do get slammed with a lot of these lately:
88.191.246.122 - - [25/Jan/2014:03:53:35 -0500] "GET /phpTest/zologize/axa.php HTTP/1.1" 404 - "-" "-"
88.191.246.122 - - [25/Jan/2014:03:53:35 -0500] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 - "-" "-"
88.191.246.122 - - [25/Jan/2014:03:53:36 -0500] "GET /pma/scripts/setup.php HTTP/1.1" 404 - "-" "-"
88.191.246.122 - - [25/Jan/2014:03:53:36 -0500] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 - "-" "-"

114.24.161.251 - - [25/Jan/2014:05:10:46 -0500] "GET /phpTest/zologize/axa.php HTTP/1.1" 404 - "-" "-"
114.24.161.251 - - [25/Jan/2014:05:10:47 -0500] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 - "-" "-"
114.24.161.251 - - [25/Jan/2014:05:10:47 -0500] "GET /pma/scripts/setup.php HTTP/1.1" 404 - "-" "-"
114.24.161.251 - - [25/Jan/2014:05:10:48 -0500] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 - "-" "-"

89.248.169.48 - - [25/Jan/2014:00:45:50 -0500] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 200 5670 "-" "ZmEu"

Maybe this is related? I have scanned and compared all my files and should be all clean now. I had one incident but it is removed now.

Thanks.

Those hits from the log you just posted are people probing for vulnerabilities in other software. I'd suggest asking your hosting company to set up some mod_security rules to block those visitors when they attempt to hit those URLs.

When you said things hang in the last step of an order, how does that translate into losing orders? If the last step is hanging when sending an email, that means the order is paid and completed.
Still, sorting out whatever is causing the delay within your host's server is important.

DrByte:

Those hits from the log you just posted are people probing for vulnerabilities in other software. I'd suggest asking your hosting company to set up some mod_security rules to block those visitors when they attempt to hit those URLs.

When you said things hang in the last step of an order, how does that translate into losing orders? If the last step is hanging when sending an email, that means the order is paid and completed.
Still, sorting out whatever is causing the delay within your host's server is important.

DR Byte, I have the exact same problems as mydanilo. I am using 1.5.1. The hang up on the last part of the order causes people to click twice and results in a double order. I posted about this some months ago. At that time I didnt realize what was causing the double orders.
My SMTPAUTH works for a few days and goes out and I have to switch to PHP. It's very odd how similar our problems are.
I have multiple stores installed for different clients but this one gets the most hits by far. We increased our hosting package to accomodate more php requests but it didnt help.
My client wants to go with another ecommerce solution and I dont know what to tell them except that i understand.

What would you recommend as the best way to debug this?

1. I've no idea what's causing your SMTP service to break intermittently. I'd say that's a hosting issue, and not related to "increasing ability for more PHP requests".

2. Zen Cart v1.5.3 uses an upgraded email infrastructure, which might be able to better withstand whatever SMTP issues you're having. I can't guarantee that it'll fix the issues, but it's worth a try, especially since upgrading also includes a number of other speed and security improvements and bugfixes. Plus it's also compatible with newer up-to-date PHP versions, so you'll be ready for any server updates your host might do.