Order Confirmation Emails Not Sending due to TCP Timeout on port 587

Help for integrating the Laravel package
Forum rules
Always add your Laravel, Aimeos and PHP version as well as your environment (Linux/Mac/Win)
Spam and unrelated posts will be removed immediately!
xarga
Posts: 43
Joined: 16 Dec 2019, 22:54

Order Confirmation Emails Not Sending due to TCP Timeout on port 587

Post by xarga » 13 Mar 2021, 05:24

AIMEOS 2019.10
Laravel 6.0
PHP 7.2
WHM/CPANEL
Centos 7.9

Recently the store has run into problems with confirmation emails failing due to a timeout issue. It appears the store is attempting to resend dozens of orders every minute inline with the cron job frequency.

This is a small section of the Aimeos log

2021-03-12 16:53:34 message 3 cb5c2db19002099ce9b169e22741cf27 Error while trying to send payment e-mail for order ID "2071" and status "6": Connection to tcp://thefrenchgourmet.com:587 Timed Out
2021-03-12 16:53:34 message 3 9b1c9699ad48996ed7d3729cde6c3908 Error while trying to send payment e-mail for order ID "2069" and status "6": Connection to tcp://thefrenchgourmet.com:587 Timed Out
2021-03-12 16:53:34 message 3 7338f30bb0cb60bf7b882c4ca92f0a9e Error while trying to send payment e-mail for order ID "2065" and status "6": Connection to tcp://thefrenchgourmet.com:587 Timed Out
2021-03-12 16:53:34 message 3 2dab96a60f7301aae53ff8b60fd4a5bd Error while trying to send payment e-mail for order ID "2067" and status "6": Connection to tcp://thefrenchgourmet.com:587 Timed Out
2021-03-12 16:53:34 message 3 ec4c3e6bafc9966856dbdc825ac82fea Error while trying to send payment e-mail for

The data center system engineers have done a thorough job of testing the mail system and it appears to be running normally. This points the issue to the external Office365 mail server the domains MX record points to or an issue with Aimeos.

The server recently underwent an update from Centos 6 to 7.9 and a week later the issue was noticed. - This suggests a settings problem or perhaps a PHP issue. We did notice that a restart of the exim mail server was the only thing that freed up a bunch of emails in case that gives any clue as to the cause of the problem.

.ENV
------------------------------------------------------------------
APP_NAME=Laravel
APP_ENV=local
APP_KEY=base64:********************************
APP_DEBUG=1
APP_URL=https://shop.thefrenchgourmet.com
LOG_CHANNEL=stack
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=fgourmet_****
DB_USERNAME=fgourmet_****
DB_PASSWORD=************
BROADCAST_DRIVER=log
CACHE_DRIVER=file
QUEUE_CONNECTION=sync
SESSION_DRIVER=file
SESSION_LIFETIME=120
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=
REDIS_PORT=6379

MAIL_DRIVER=smtp
MAIL_HOST=thefrenchgourmet.com
MAIL_PORT=587
MAIL_ENCRYPTION=TLS
MAIL_USERNAME=orders@shop.thefrenchgourmet.com
MAIL_PASSWORD=*************
MAIL_FROM_ADDRESS=orders@shop.thefrenchgourmet.com
MAIL_FROM_NAME=Orders

shop.php
-----------------------------------------------------
'client' => [
'html' => [
'email' => [
'from-email' => 'orders@shop.thefrenchgourmet.com',
'from-name' => 'The French Gourmet',
'payment'=>[
'bcc-email'=>'orders@thefrenchgourmet.com',
'reply-email' => 'orders@thefrenchgourmet.com',
/*sends copy of confirmation email sent to client */
],
],

from mail.php
------------------------------------------------
host' => env('MAIL_HOST', 'shop.thefrenchgourmet.com'),
'from' => [
'address' => env('MAIL_FROM_ADDRESS', 'hello@example.com'),
'name' => env('MAIL_FROM_NAME', 'Example'),
],

HEADERS FROM A SUCCESSFUL ORDERCONFIRMATION EMAIL
-------------------------------------------------------------------
Return-Path: <orders@thefrenchgourmet.com>
Received: from server2.acorninteractive.com
by server2.acorninteractive.com with LMTP
id *****************
(envelope-from <orders@thefrenchgourmet.com>); Thu, 11 Mar 2021 20:39:40 -0500
Return-path: <orders@thefrenchgourmet.com>
Envelope-to: xarga@acornnteractive.com
Delivery-date: Thu, 11 Mar 2021 20:39:40 -0500
Received: from server2.acorninteractive.com ([138.128.181.34]:43010 helo=[127.0.0.1])
by server2.acorninteractive.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94)
(envelope-from <orders@thefrenchgourmet.com>)
id 1lKWlf-00085M-C3
for xarga@acorninteractive.com; Thu, 11 Mar 2021 20:39:07 -0500

Message-ID: <e375cd34bd84da1c81472128945a0f68@swift.generated>
Date: Thu, 11 Mar 2021 17:39:07 -0800
Subject: Order Confirmation - The French Gourmet. Order No. 2011
From: The French Gourmet <orders@thefrenchgourmet.com>
Reply-To: The French Gourmet <orders@thefrenchgourmet.com>
To: MY NAME <xarga@acorninteractive.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="_=_swift_1615513147_aa714318f6ef3eeead2076adcf75f470_=_"
X-MailGenerator: Aimeos
X-Antivirus: Avast (VPS 210311-8, 03/12/2021), Inbound message
X-Antivirus-Status: Clean
X-Antivirus: avast! (VPS 210311-8, 3/11/2021), Inbound message
X-Antivirus-Status: Clean

FROM THE DATA CENTER ENGINEERS
-------------------------------------------------------------

After further investigation this does not appear to be a server or service related issue based on our findings. The current main issue reported by the site's logs is a time out issue when connecting to the domain "thefrenchgourmet.com" on port 587.
In effort to proof/replicate connection issues we attempted connections to the server and performed a manual mail transaction attempt for possible issues related to time out or otherwise.
From this we found we were unable to replicate the issue described as we were able to connect to the server, authenticate and see a successful relay attempt to Outlook's servers where this domain's mail host is located.
Please note that this was created with an email testing account created on the domain "thefrenchgourmet.com" specifically for troubleshooting your issue.

You can review the entirety of our connection attempt below:
=========================================
telnet thefrenchgourmet.com 587
Trying 138.128.181.34...
Connected to thefrenchgourmet.com.
Escape character is '^]'.
220-server2.acorninteractive.com ESMTP Exim 4.94 #2 Fri, 12 Mar 2021 06:13:19 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
EHLO
250-server2.acorninteractive.com Hello vpn-pool.dimenoc.com [72.29.91.30]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-X_PIPE_CONNECT
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
AUTH LOGIN ********************************
334 ***********
e24xP0tMOU1acVAh
235 Authentication succeeded
MAIL FROM:hdtest@thefrenchgourmet.com
250 OK
RCPT TO:hdtest@thefrenchgourmet.com
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
Subject: Test TCP Connect.
Test for host connection.
.
250 OK id=1lKfm0-0002vu-0W
quit
221 server2.acorninteractive.com closing connection
Connection closed by foreign host.
=========================================

From here we then reviewed the way the server processed this connection and we were able to see it was able to resolve that the mail host for the domain is with Outlook which you can see below:
=========================================
2021-03-12 06:18:02 1lKfm0-0002vu-0W

From this we are able to confirm that the server is open to connections on that specified port, is able to successfully process and resolve emails and attempt delivery to a remote network. From this we would recommend to reach out to the site's CMS developer which appears to be Aimeos who would be better familiar with reviewing the site and troubleshooting or identifying possible issues. As we are not specialized in site development nor troubleshooting there could be a configuration we may have missed on the site itself. From the above we were able to confirm that there is no issue with the service or server itself and it is functioning as intended.
If you find that there is a server configuration recommended by Aimeos or the site's developer/maintainer which needs to be adjusted we can assist you with making those necessary changes.

We would also recommend to contact Outlook to see if any available logs are present for connections from the server when it is attempting to relay the mail for your site or any blockers that could be occurring on their side as well.

User avatar
aimeos
Administrator
Posts: 7895
Joined: 01 Jan 1970, 00:00

Re: Order Confirmation Emails Not Sending due to TCP Timeout on port 587

Post by aimeos » 14 Mar 2021, 14:57

If there's a timeout when connecting to that port and no e-mails are sent at all, check if the PHP processes are allowed to connect to that port and no SELinux security rules are forbidding that.
Professional support and custom implementation are available at Aimeos.com
If you like Aimeos, Image give us a star

xarga
Posts: 43
Joined: 16 Dec 2019, 22:54

Re: Order Confirmation Emails Not Sending due to TCP Timeout on port 587

Post by xarga » 15 Mar 2021, 21:20

We've confirmed that this server is not using SELinux security rules. Because port 587 is open, PHP processes should have access to it without any issues.

The data center techs engineers requested we ask Aimeos to clarify on what PHP processes would need access so that their team may further investigate.

User avatar
aimeos
Administrator
Posts: 7895
Joined: 01 Jan 1970, 00:00

Re: Order Confirmation Emails Not Sending due to TCP Timeout on port 587

Post by aimeos » 16 Mar 2021, 10:40

We had a similar problem on a CentOS system that httpd couldn't access port 9200 and got around with:

Code: Select all

setsebool -P httpd_can_network_connect 1
You can also install setroubleshoot-server RPM and run:

Code: Select all

 sealert -a /var/log/audit/audit.log 
it will give you a nice report with useful suggestions

This was also helpful: https://serverfault.com/questions/56387 ... cific-port
Professional support and custom implementation are available at Aimeos.com
If you like Aimeos, Image give us a star

xarga
Posts: 43
Joined: 16 Dec 2019, 22:54

Re: Order Confirmation Emails Not Sending due to TCP Timeout on port 587

Post by xarga » 17 Mar 2021, 04:39

From the Datacenter technicians:

We noticed that the developer returned with troubleshooting steps that assume that SELinux is enabled on this server. As was confirmed in our last response, SELinux is disabled on this server and, as such, would not be causing any issues for the software being used.

If they return with additional/alternative troubleshooting steps, we are happy to assist in attempting them.

Post Reply