No emails from PHP with fastcgi and email anti spoofing protection

[Dettol]

Well... in the old days maybe. Nowadays chances are very big that recipient servers will just bluntly refuse those mails. At least Gmail and Microsoft will refuse e-mails without either SPF or DKIM record.
On our servers we also bluntly refuse mail without SPF record if I remember correctly.

It was also Microsoft always to begin with. They didn't see that as a good measure in the beginning. And at a certain point they started and now they use a very strict rule about SPF and DKIM since start of juni or juli this year. If hey had being more cooperating in the beginning, with several things, we would have a lot less spam these days.

What DA is doing is not a fix but a security measure, like was done with exim and dovecot before already with authenticating.
And I agree that at least certain security measures should not be implemented by default, but should be optional (like now disabling is) so hosting company's won't run into certain issues because some security issue is entered without knowledge. Because loads of DA customers to not visiti the forums.
Some measures would be great, but only if everybody is using them, like the authentication improvement. But other panels should do that too.

SMTP does not really need to be replaced. IMAP and POP also did not get replaced, they got improved and yes indeed that is something which SMTP would need too. I think that is what you ment.
But it must be done with an RFC because you need to get it improved worldwide with all parties changing it, like was done with pop and imap.

I completely agree with your statement. This recent update, which was enforced, has caused many of my users to complain, with some even asking if I realize how much loss this has caused me. I hope they won't adopt a one-size-fits-all approach. Even with similar updates, it would be better if they were set to off by default, allowing us to choose whether to enable them. This way, even if we decide to activate them, we would have time to inform our users about the necessary updates or precautions.

 

[Dettol]

@sec-is, please do not post AI generated content in the forums. It is relatively easy to coerce AI to give you the answer you prefer to see.



Yes you can set this up upfront. The option that disables this security check is an Exim macro. Exim allows you to define new macros even if they are not (yet) being used.



This feature is designed to discourage all new DA users for setting up their web applications in a way that uses sender impersonation.

The existing users can disable this feature if they were using sender impersonation over SMTP and are not willing to update the SMTP credentials to match the sender address.

Note, web application can use the native PHP mail() function for sending emails. It does not require authentication.

Hi there,

I'd like to respectfully share my direct experience regarding this part of the official note, as it might be causing some confusion:

Note, web application can use the native PHP mail() function for sending emails. It does not require authentication.

While this statement is technically true from the perspective of a PHP script (the mail() function itself doesn't require credentials), my experience after updating to 1.680+ is that the outcome is different.

On a standard, updated server with the new default security settings (block_sender_spoofing=yes), any attempt to send an email using the native mail() function consistently fails. The mail is blocked by Exim.

The reason is that Exim's new ACLs now seem to reject any mail that doesn't originate from a properly authenticated SMTP session. Since phpmail() sends as a system user without performing an SMTP login, it gets caught and blocked by this new, stricter rule. We were only able to make phpmail() work again by disabling this security feature (block_sender_spoofing=no), which defeats the purpose of the update.

Perhaps the official documentation could be clarified to better reflect this? A more accurate statement might be:

"While the PHP mail() function can be called without credentials, emails sent this way will be blocked by Exim's new default security settings. We strongly recommend configuring all web applications to use authenticated SMTP for mail delivery."

This small change in wording would likely save many users a lot of troubleshooting time. Thanks for the great work on DirectAdmin!

 

[JosKlever]

"While the PHP mail() function can be called without credentials, emails sent this way will be blocked by Exim's new default security settings. We strongly recommend configuring all web applications to use authenticated SMTP for mail delivery."

Then you have other issues probably, because PHP mail is still working on my servers while I haven't disabled the new security measures. It might be a good idea to check the addresses that are used to send the email.

 

[Dettol]

Then you have other issues probably, because PHP mail is still working on my servers while I haven't disabled the new security measures. It might be a good idea to check the addresses that are used to send the email.

That's a very interesting data point, thank you for sharing. This actually strengthens my belief that the issue lies within DirectAdmin's default configuration, and that your success might be due to a specific, non-default setup on your server.

On my end, this is a standard, out-of-the-box DirectAdmin installation. The only action that makes PHP mail() work is setting block_sender_spoofing=no. Toggling it back to yes immediately breaks it again. This is a clear cause-and-effect relationship.

You mentioned checking the addresses, which is a great point. It makes me wonder about the specifics of your working setup, as it clearly differs from a default installation. Could you perhaps clarify a few things so we can find the difference?

1. In your exim.conf, is the phpmail() sender being processed by a special ACL, or is your system user (e.g., apache or the DA username) listed in a trusted_users or a similar whitelist?
2. What specific address are you using in the From: header of your PHP mail() function? Does it exactly match the DA user's default email (username@hostname)?

My hypothesis is that your server has a custom trust rule that a default DA installation lacks. If so, it perfectly illustrates the problem: the new security measures, in their default state, are breaking a core PHP function for many users.

 

[Ohm J]

@fln @Dettol
About Exim, there have some chance when using php_mode other than php-fpm,.... like fastcgi, the script might execute by "apache" user and completely broken the PHP mail().

 

[JosKlever]

@Dettol I'm not aware that I have a special configuration, so in my opinion it's quite standard.

In your exim.conf, is the phpmail() sender being processed by a special ACL, or is your system user (e.g., apache or the DA username) listed in a trusted_users or a similar whitelist?

Where should I find this? I don't have "php" in /etc/exim.conf except for a documentation link in a comment line. And I don't see anything related to ACL that I might have modified. Same for trusted/whitelisted users.

What specific address are you using in the From: header of your PHP mail() function? Does it exactly match the DA user's default email (username@hostname)?

It's what WordPress uses by default (like [email protected]) or a specified address belonging to the domain of the site. It doesn't matter if the address exists as an actual mailbox. And I don't have catch-all configured. So I think it should just work as long as the address corresponds with the domain name.

 

[Dettol]

@fln @Dettol
About Exim, there have some chance when using php_mode other than php-fpm,.... like fastcgi, the script might execute by "apache" user and completely broken the PHP mail().

Yes, exactly! Thank you for highlighting this crucial point. You've absolutely nailed the root cause of why different users are seeing different results.

This distinction between PHP handlers is the key piece of the puzzle. It perfectly explains the situation:

• Users whose phpmail() still works are most likely running modern setups like php-fpm, where the script is executed by the actual DA user (e.g., client1).
• Users like me, whose phpmail() broke immediately after the update, are likely on setups where the script is executed by a generic, low-trust system user like apache.

And Exim's new block_sender_spoofing rule is designed to do precisely one thing: block unauthenticated mail from untraceable sources like the apache user.

This confirms that relying on the native phpmail() is no longer a viable strategy in the long run. The only robust, future-proof solution that works across all these different server configurations is to configure our applications to use authenticated SMTP.

Thanks again for clarifying this critical technical detail for the community.

 

[Dettol]

@Dettol I'm not aware that I have a special configuration, so in my opinion it's quite standard.


Where should I find this? I don't have "php" in /etc/exim.conf except for a documentation link in a comment line. And I don't see anything related to ACL that I might have modified. Same for trusted/whitelisted users.

It's what WordPress uses by default (like [email protected]) or a specified address belonging to the domain of the site. It doesn't matter if the address exists as an actual mailbox. And I don't have catch-all configured. So I think it should just work as long as the address corresponds with the domain name.

Thank you for the detailed follow-up. It's clear your setup is working for you, and the mystery of why our experiences differ is a fascinating one.

In fact, another user in this thread, Ohm J, just posted a brilliant insight that I believe solves this puzzle entirely. They pointed out:

"there have some chance when using php_mode other than php-fpm,.... like fastcgi, the script might execute by "apache" user and completely broken the PHP mail()."

This is the key. This single point explains everything perfectly.

It means that whether phpmail() works or not depends entirely on the PHP handler your server uses:

1. Your working scenario: Your server is most likely running on php-fpm. In this mode, the PHP script is executed by the actual DA user (e.g., client1). This is a more trusted, traceable source, and for some reason, Exim on your specific setup is allowing it to pass even without SMTP authentication.
2. My (and others') failing scenario: Our servers are likely running on an older handler (mod_php, or a specific fastcgi setup) where the script is executed by the generic, low-trust apache user. Exim's new block_sender_spoofing rule is precisely designed to block this kind of anonymous, untraceable mail.

So, your setup isn't "special" because you manually changed it, but because your server's default PHP environment happens to fall into a category that bypasses the new rule's strictest check.

This whole situation confirms that relying on phpmail() is now unpredictable. The only universal, 100% reliable solution that works across all these different configurations is to set up applications like WordPress to use proper, authenticated SMTP with a real email account.

Building on the point about phpmail()'s unreliability under new security measures, it's worth noting that this is why popular web applications like WordPress have dedicated solutions.

Plugins like WP Mail SMTP are a perfect example. They allow WordPress to send emails by configuring it to use an external SMTP server (or an authenticated local one), completely bypassing the native mail() function and its issues with DirectAdmin's new block_sender_spoofing rules. They essentially do exactly what we've been discussing: they use authenticated SMTP to send mail, which is why they remain unaffected.

 

[JosKlever]

Your working scenario: Your server is most likely running on php-fpm. In this mode, the PHP script is executed by the actual DA user (e.g., client1). This is a more trusted, traceable source, and for some reason, Exim on your specific setup is allowing it to pass even without SMTP authentication.

I'm actually using lsphp as I'm running OpenLiteSpeed, but if not it would have been php-fpm, as that's the recommended value for Nginx/Apache as far as I know.

So, your setup isn't "special" because you manually changed it, but because your server's default PHP environment happens to fall into a category that bypasses the new rule's strictest check.

It's just a default modern setup, not changed on purpose. One server is on AlmaLinux 8 for about 4 years and one is on AlmaLinux 10 and has just been live for a month.

So I think that it's mainly breaking on older setups that are not out-of-the-box anymore. I'll let the up to others to comment on. I'm just saying that you are generalizing the issues too much. Yes, some users might have issues, but not all of them and probably also not most of them. Try to avoid claims using 100% and "all" etc.

 

[Dettol]

I'm actually using lsphp as I'm running OpenLiteSpeed, but if not it would have been php-fpm, as that's the recommended value for Nginx/Apache as far as I know.

It's just a default modern setup, not changed on purpose. One server is on AlmaLinux 8 for about 4 years and one is on AlmaLinux 10 and has just been live for a month.

So I think that it's mainly breaking on older setups that are not out-of-the-box anymore. I'll let the up to others to comment on. I'm just saying that you are generalizing the issues too much. Yes, some users might have issues, but not all of them and probably also not most of them. Try to avoid claims using 100% and "all" etc.

Thank you for this excellent and clarifying response. I believe we are now in complete agreement and have successfully identified the root cause of this entire issue.

You are absolutely right. Your confirmation of using lsphp (which functions like php-fpm) is the final piece of the puzzle. It proves that the PHP handler is the deciding factor.

I also agree with your conclusion: this issue primarily breaks older setups. And that is precisely the core of the problem I wanted to highlight. Many of us are running servers that have been stable for years with handlers like mod_php or specific fastcgi modes. For these systems, that configuration was the "out-of-the-box" standard for a long time.

A security update, however well-intentioned, that silently breaks a core function for this significant portion of the user base is the exact reason why a "smoother transition" with clearer warnings is needed.

You also make a fair point about my use of absolutes like "all" or "100%". I'll be more precise: this update is causing issues for a significant number of users whose servers are configured with a PHP handler that executes scripts as a generic system user like 'apache'.

So, in the end, we are saying the same thing from two different perspectives. You are representing a modern, default setup where everything works. I am representing the large group of users with long-standing, previously-standard setups that are now broken by this change.

Hopefully, this discussion can help DirectAdmin provide better guidance for everyone in the future. Thanks again for the productive conversation.

 

[fln]

@Dettol. The default DA installation using apache webserver and PHP fastcgi mode works fine with anti spoofing protection turned on.

I think something specific to your server might be causing issues. Please open a support ticket and we will check it out.

Quick test. Place this script (change the [email protected] to your actually functional mailbox):

<?php
mail("[email protected]", "Email from PHP", "This email is from ".$_SERVER['HTTP_HOST']."/".$_SERVER["SCRIPT_FILENAME"]);

In one of the client domains, for example at /home/user/domains/example.com/public_html/mail_test.php. And execute this script with a simple web request curl https://example.com/mail_test.php.

It should send an email to your mailbox on every request.

 

[Dettol]

@Dettol. The default DA installation using apache webserver and PHP fastcgi mode works fine with anti spoofing protection turned on.

I think something specific to your server might be causing issues. Please open a support ticket and we will check it out.

Quick test. Place this script (change the [email protected] to your actually functional mailbox):

<?php
mail("[email protected]", "Email from PHP", "This email is from ".$_SERVER['HTTP_HOST']."/".$_SERVER["SCRIPT_FILENAME"]);

In one of the client domains, for example at /home/user/domains/example.com/public_html/mail_test.php. And execute this script with a simple web request curl https://example.com/mail_test.php.

It should send an email to your mailbox on every request.

Thank you for your reply and for providing the test script.

I understand that the provided mail() function script works correctly in a default setup. However, the core of the issue I am facing, which is also the standard practice for most modern applications, is sending mail via SMTP authentication (e.g., using libraries like PHPMailer). These two methods are fundamentally different in their underlying mechanisms.

You mentioned that "something specific to your server might be causing issues," and you are correct, but it is not a server failure. After extensive troubleshooting, we have confirmed that the root cause is the default security policy of the CSF firewall. By default, CSF blocks non-root users (such as the apache or user account under which web scripts run) from making outbound SMTP connections, whether to localhost:587 or an external server like smtp.gmail.com. This is what causes the "Connection refused" error.

The mail() function test you suggested uses an internal delivery path and therefore does not trigger this network connection restriction, which is why it succeeds. However, it fails to replicate the real-world scenario that applications encounter when they need to perform SMTP authentication.

This finding precisely confirms my original point: for many standard applications that rely on SMTP authentication, this is a "silent" breaking change caused by a default firewall policy.

Therefore, I would like to reframe the question into a more constructive inquiry: For customers who need to authenticate via SMTP from their web applications (a very common use case), what is the officially recommended best practice? Is the advice for administrators to manually whitelist users in CSF's SMTP_ALLOWUSER, or are there other, more systematic solutions?

Thank you again for your help; this has helped clarify the true nature of the issue.

 

[fln]

Thanks for clarification. You are right, using SMTP for sending emails from PHP is as popular if not more popular than sending directly with PHP mail() function.

Just to recap:

• Scripts that are using PHP mail() function for email sending (no SMTP configuration) are not affected by the new Exim sender spoofing block feature.
• Scripts that are using SMTP for email sending can be affected, but only if they actually do the sender spoofing action. In other words try to send email from a different sender addres. If they are being blocked by CSF it has nothing to do with the Exim sender spoofing block feature.

On a standard DA installation the default CSF configuration should not be blocking the connections to locally running exim on SMTP ports - TCP 465 and TCP 587! The CSF configuration and Exim sender spoofing block are not related. If CSF was blocking local SMTP connections it would should be blocking them even before the introduction of Exim sender spoofing block feature.

It would be great to find out why CSF is blocking local connections. It should not be the case for most servers. Please check the following:

• Make sure /etc/csf/csf.conf has SMTP_ALLOWLOCAL = "1". This should be default on all servers. It makes sure connections to local mail server is not blocked.
• Make sure SMTP configuration in PHP scripts are using submission port (TCP 587 or 465) for sending emails over SMTP. Not TCP 25 port.
• Make sure /etc/csf/csf.conf has SMTP_PORTS = "25", not SMTP_PORTS = "25,465,587". This makes sure PHP scripts can use external mail servers (like gmail or other SMTP providers).

When CB configures CSF it changes SMTP_PORTS to be only TCP 25 port. But if your server is quite old and CB never got a chance to update CSF configuration (it does it when rebuilds a software that needs CSF config changes) then you might have the default value that includes submission ports as SMTP ports.

It is quite safe to allow external connections to 465 and 587 ports because these are submission ports and usually require authentication before sending email.

 

[Dettol]

Thanks for clarification. You are right, using SMTP for sending emails from PHP is as popular if not more popular than sending directly with PHP mail() function.

Just to recap:

• Scripts that are using PHP mail() function for email sending (no SMTP configuration) are not affected by the new Exim sender spoofing block feature.
• Scripts that are using SMTP for email sending can be affected, but only if they actually do the sender spoofing action. In other words try to send email from a different sender addres. If they are being blocked by CSF it has nothing to do with the Exim sender spoofing block feature.

On a standard DA installation the default CSF configuration should not be blocking the connections to locally running exim on SMTP ports - TCP 465 and TCP 587! The CSF configuration and Exim sender spoofing block are not related. If CSF was blocking local SMTP connections it would should be blocking them even before the introduction of Exim sender spoofing block feature.

It would be great to find out why CSF is blocking local connections. It should not be the case for most servers. Please check the following:

• Make sure /etc/csf/csf.conf has SMTP_ALLOWLOCAL = "1". This should be default on all servers. It makes sure connections to local mail server is not blocked.
• Make sure SMTP configuration in PHP scripts are using submission port (TCP 587 or 465) for sending emails over SMTP. Not TCP 25 port.
• Make sure /etc/csf/csf.conf has SMTP_PORTS = "25", not SMTP_PORTS = "25,465,587". This makes sure PHP scripts can use external mail servers (like gmail or other SMTP providers).

When CB configures CSF it changes SMTP_PORTS to be only TCP 25 port. But if your server is quite old and CB never got a chance to update CSF configuration (it does it when rebuilds a software that needs CSF config changes) then you might have the default value that includes submission ports as SMTP ports.

It is quite safe to allow external connections to 465 and 587 ports because these are submission ports and usually require authentication before sending email.

Thank you so much for your incredibly detailed and insightful response! It has been tremendously helpful in pinpointing the root cause of the issue.

You were absolutely right. The core of the problem was indeed in the CSF configuration, specifically with the SMTP_PORTS parameter.

Following your guidance, I checked my /etc/csf/csf.conf file and found that my SMTP_PORTS was indeed set to "25,465,587". After changing it to just "25" and restarting CSF (csf -r), my PHPMailer script can now successfully connect to localhost:587 for authenticated sending. The problem is completely resolved! I also confirmed that my SMTP_ALLOWLOCAL was already set to "1".

I now fully understand that this modification ensures CSF's SMTP blocking rules only apply to the traditional port 25, allowing the authenticated submission ports (465 and 587) to function as expected, which is precisely the standard behavior we were looking for.

Thank you again for your professional guidance. You've not only solved my immediate problem but have also given me a much deeper understanding of the security configurations in a DirectAdmin environment.

 

[Richard G]

After changing it to just "25" and restarting CSF (csf -r), my PHPMailer script can now successfully connect to localhost:587 for authenticated sending. The problem is completely resolved! I also confirmed that my SMTP_ALLOWLOCAL was already set to "1".

That part I totally do not understand.

Make sure /etc/csf/csf.conf has SMTP_PORTS = "25", not SMTP_PORTS = "25,465,587". This makes sure PHP scripts can use external mail servers (like gmail or other SMTP providers).

I don't understand this one at all combined with the above. When limiting this setting to 25, one would expect that only 25 could be used for SMTP.
So how come when -not- allowing port 465 and 587 in SMTP_PORTS it allowes them to be used? And if present, they get blocked while present in SMTP_PORTS, one should expect them to be allowed to be used. Very confusing this.

 

[fln]

I don't understand this one at all combined with the above.

Quick summary of CSF settings:

• SMTP_BLOCK = "1" - make sure only root and Exim are allowed to deliver outgoing email. This means adding a firewall rule that will check process UID and block outgoing SMTP connections if owner is not root or exim.
• SMTP_ALLOWLOCAL = "1" - adds an exception for the rule above to allow SMTP connections if the destination is lo (loopback) interface. This means any user on system can connect to localhost but still get blocked if they try to connect to external servers.
• SMTP_PORTS = "25" - makes sure that all the rules above (blocking SMTP connections) apply only when destination port is TCP 25. If the list is longer, then the rules above (blocking SMTP connections) will apply to all listed ports (for example, submission) as well.

There is huge value in blocking users from connecting to outside using TCP 25 port. This means a hacked website cannot be used to just send spam by directly connecting to MTAs over TCP port 25. They do this by either connecting to the destination domain MX server or connecting to any misconfigured (open relay) server on the internet. This forces hacked websites to send using a local exim service which has various restrictions (like limiting number of emails per day, counting failed recipients, etc.).

There is practically no value in blocking users from connecting to outside using TCP 465 or TCP 587 ports (submission). This is because these ports are used for authenticated clients only.

---

RFC6409 has more details:

4.3.  Require Authentication

   The MSA MUST, by default, issue an error response to the MAIL command
   if the session has not been authenticated using [SMTP-AUTH], unless
   it has already independently established authentication or
   authorization (such as being within a protected subnetwork).

TCP port 25 - used by MTA (Exim on DA servers). MTA server that manages @example.com domain will receive emails where @example.com is the destination of the email. It requires no authentication and accepts emails for @example.com from any server.

TCP port 465/587 - used by MSA (also Exim on DA servers) to receive emails from MUA (Roundcube, Thunderbird, Outlook, ...) and will deliver them to the internet. Server that manages @example.com domain will receive emails where @example.com is the sender address of the email. It requires authentication to only allow access for the users who own @example.com account. Without authentication it would become an open relay.

 

[sparek]

SMTP_PORTS in this context, is defining what ports CSF should block underprivileged users from connecting to directly.

In the olden days, there was a script called Dark Mailer (I'm sure there were a lot of others) that worked by connecting directly to mail exchange servers on port 25 to send out spam. In this way, your server's IP address was implicated because it was where the message was coming from, but since it was done by connecting directly to a recipient's mail exchange on port 25, there was no log of it.

Effectively, it allowed under privileged users (web hosting users) to connect directly to hotmail-com.olc.protection.outlook.com on port 25 and do a full SMTP transaction to send emails to various @hotmail.com email accounts.

What this setting in CSF is doing is defining an iptables that blocks users (users that aren't defined in SMTP_ALLOWUSER or group'd in SMTP_ALLOWGROUP) from connecting directly to port 25 for any host. Effectively killing the ability to use these Dark Mailer scripts.

By listing only port 25 here, you still allow outbound connections to port 587 and port 465 (or any other ports for any mail service that you might be using). But as @fln pointed out these are commonly message submission ports that require SMTP authentication before it will accept any email. Another words, you can't connect to hotmail-com.olc.protection.outlook.com on port 587 and send an email to a random @hotmail.com email user. Of course... if a mail server is allowing mail to be relayed out through connection on port 587 and 465... then a script like Dark Mailer would still work. But if a mail server is allowing that, then it's misconfigured.

You have to understand that sending mail from server to server with SMTP is designed be done on port 25 and port 25 only. This is defined as an MTA. When your email client is connecting to a mail server to send an email to a recipient, that is MSA (Message Submission Agent). Now the confusing part is, port 25 CAN be used for both of these. It's entirely possible that your email client (MUA - Mail User Agent) is connecting to it's outgoing mail server (MSA) on port 25 and then that server is sending that message (MTA) to the recipient's mail server on port 25 as well. But in recent times, port 587 and port 465 (implict TLS - the connection is encrypted before it reaches the mail server) have been preferred as MSA ports to help differentiate this. The protocol for MTA and MSA is still the same - SMTP - but commonly MSA ports require authentication to prove that you are allowed to send mail through this system. So while port 25 can be an MSA and MTA port, the same is not true for ports 587 and 465. Ports 587 and 465 are not designed to be MTA ports. They are intended as MSA ports only.

So what's happening here with CSF. CSF is going to prevent local under privileged users on the server from connecting to any host on port 25. But those same users can still connect on port 587 or 465 on the localhost - AND authenticate themselves to the mail server - and still be able to send out mail.

 

[Richard G]

If the list is longer, then the rules above (blocking SMTP connections) will apply to all listed ports (for example, submission) as well.

Ahaaa.... oke that was where I was wrong. That makes sense and explains my confusion. Thank you!