Lamp - PHP mailer not working after last lamp and mail apps update

Hi,I am using php mailer in my php script running in lamp app, connecting to the smtp server in a mail app on the same NS8 node, sending mails just to NS8 users. It was working perfectly for months till the last lamp and mail apps update. Now it throws an error:

Mailer Error:SMTP Error: Could not connect to SMTP host. Failed to connect to server SMTP server error: Failed to connect to server SMTP code: 111 Additional SMTP info: Connection refused

The respective php code is:

$headers = "From: " . $senderEmail;
$mail = new PHPMailer(true);
try {
    $mail->isSMTP();
    $mail->Host = $smtpServer;
    $mail->SMTPAuth = true;
    $mail->Username = $username;
    $mail->Password = $password;
    $mail->SMTPSecure = 'tls';
    $mail->Port = 587;
    
    $mail->CharSet = 'UTF-8';
    $mail->Encoding = 'base64';

    $mail->setFrom($senderEmail, $senderName);
    $mail->addAddress($emailTo);
    $mail->Subject = $subject;
    $mail->Body =  $body;

    $mail->send();
} catch (Exception $e) {
    echo("Mailer Error:" . $mail->ErrorInfo);
} 

PHP mailer ver. 6.12.0
SMTP access from clients in LAN works without problem (on TLS/587)
I have also tried to switch php mailer to relay on port 25 without authentication (with appropriate relay settings in the maill app), but without success.

I think I could reproduce it.

I guess the nodes FQDN is the same as the mail server hostname.

Setting the nodes FQDN sets an entry in the hosts /etc/hosts:

127.0.1.1 node.domain.tld node

The hosts /etc/hosts is also used in the containers like the apache2-app container of the lamp app. So when the PHPMailer script is executed in the lamp container and it wants to connect to the mail server at node.domain.tld it doesn’t reach it as it connects to 127.0.1.1 which is the lamp container itself and not the mail server.

So I changed the nodes FQDN at the nodes page to another name which adapts the /etc/hosts entry, see Cluster management — NS8 documentation
Be careful to set a name that points to the server to reach it again. In case something went wrong, it should always be possible to reach the cluster admin using the IP.
If you obtained a certificate for the node don’t forget to get a new one.

Then I restarted lamp to use the corrected /etc/hosts:

runagent -m lamp1 systemctl --user restart apache2-app

Now the mail server FQDN was reachable from the lamp app and PHPMailer worked.

2 Likes

Yes, thank you @mrmarkuz, now it works again.
Even it seems, that just the restart of apache2-app refreshed the host entry.

1 Like

not sure if needed but the smarthost variables are available inside the container

[lamp1@ns8-leader state]$ cat smarthost.env
SMTP_ENABLED=1
SMTP_HOST=10.5.4.1
SMTP_PORT=25
SMTP_USERNAME=
SMTP_PASSWORD=
SMTP_ENCRYPTION=none
SMTP_TLSVERIFY=

this is dynamic at any restart of the container, and comes from the smarthost setting you have set for the whole cluster

2 Likes
1 Like

Hi,
I am developing another web application, this time on the NS8 Webserver app, and I am getting the same problem, as was resolved with the LAMP app earlier.

SMTP Error: Could not connect to SMTP host. Failed to connect to server SMTP server error: Failed to connect to server SMTP code: 111 Additional SMTP info: Connection refused

The PHP Mailer settings within the Webserver app are practically the same

  `$mail->isSMTP();`

$mail->Host = <ns8 Mail server hostname FQDN>;
$mail->SMTPAuth = true;
$mail->Username = 'XXX';
$mail->Password = 'XXX';
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
$mail->Port = 587;

Thank you for any suggestions

This is an output of connection I have tried from within the webserver container:

[webserver1@hur state]$ openssl s_client -connect hur.twr.cz:587 -starttls smtp
Connecting to 127.0.1.1
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let’s Encrypt, CN=R13
verify return:1
depth=0 CN=hur.twr.cz
verify return:1

Certificate chain
0 s:CN=hur.twr.cz
i:C=US, O=Let’s Encrypt, CN=R13
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Dec 24 19:19:39 2025 GMT; NotAfter: Mar 24 19:19:38 2026 GMT
1 s:C=US, O=Let’s Encrypt, CN=R13
i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT

Server certificate
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
subject=CN=hur.twr.cz
issuer=C=US, O=Let’s Encrypt, CN=R13

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits

SSL handshake has read 3990 bytes and written 437 bytes
Verification: OK

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 4096 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

250 CHUNKING

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Session-ID: …
Session-ID-ctx:
Resumption PSK: …
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
…

Start Time: 1770370457
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0




read R BLOCK

can we have the log of the remote smtp server to understand what it occurs ?

1 Like

can you try to not verify the certificate, this is an example, not sure it is relevant to your need

$mail->SMTPOptions = array(
‘ssl’ => array(
‘verify_peer’ => false,
‘verify_peer_name’ => false,
‘allow_self_signed’ => true
)
);

1 Like

if possible if you manage the NS8 mail server in the cluster you can try to use the wiregarde IP of the server and not the fqdn

1 Like

It seems the same issue as it was with lamp.

Is hur.twr.cz the mail server hostname which is also the nodes FQDN?
Because of the entry in /etc/hosts, it resolves to 127.0.1.1 which doesn’t work inside the container.

To check the SSL connection from inside the php container: (adapt php7.4 to the php version you’re using)

runagent -m webserver1 podman exec php7.4-fpm openssl s_client -connect hur.twr.cz:587 -starttls smtp

Unfortunately did not help

Is hur.twr.cz the mail server hostname which is also the nodes FQDN?

Yes it is

[root@hur admin]# /usr/local/bin/runagent -m webserver1 podman exec php7.4-fpm openssl s_client -connect hur.twr.cz:587 -starttls smtp
Error: crun: executable file openssl not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

Did you already try to change the nodes FQDN and restart webserver?

Yes I did.
Now:
Mail server hostname: hur.twr.cz
Nodes FQDN: hur-ns8.twr.cz
Did I get it right?

Yes, that’s right.

Unfortunately it is still not working.

Did you restart the webserver?

Let’s check if the hostname is in the hosts file:

runagent -m webserver1 podman exec php7.4-fpm cat /etc/hosts | grep 127.0.1.1

[root@hur etc]# /usr/local/bin/runagent -m webserver1 podman exec php7.4-fpm cat /etc/hosts | grep 127.0.1.1
127.0.1.1 hur-ns8.twr.cz hur-ns8

Yes, it did restart the webserver1 app from webgui and also the webserver service from cli:

[root@hur etc]# /usr/local/bin/runagent -m webserver1 systemctl --user restart webserver

OK, this one is strange:

Is there no openssl in the container? Does it help to use another PHP version?

runagent -m webserver1 podman exec php7.4-fpm whereis openssl

[root@hur etc]# /usr/local/bin/runagent -m webserver1 podman exec php7.4-fpm whereis openssl
openssl:

Switching to other php version does not help.
I have also tried to install fresh new Webserver instance, but it returns the same (empty) output:

[root@hur etc]# /usr/local/bin/runagent -m webserver1 podman exec php8.2-fpm whereis openssl
openssl:
[root@hur etc]# /usr/local/bin/runagent -m webserver2 podman exec php7.4-fpm whereis openssl
openssl: