Suggestions for Smoother Transitions with Future Security Updates

[Dettol]

First of all, thank you for your ongoing commitment to improving the security of the platform. The recent enhancements to Exim are a welcome and important step forward for the entire community.

As long-time users, we've noticed that the rollout of these changes presented some challenges for existing applications (like those using phpmail) and even for default configurations like Roundcube.

To help make future transitions even smoother for all users, especially those with established systems, we'd like to humbly offer a few suggestions based on our experience:

1. Consider a Temporary "Legacy Mode" or Grace Period: For significant changes, it would be incredibly helpful to have an optional, temporary setting to maintain the old behavior. This would give administrators a crucial grace period to audit and update their applications without facing immediate service disruption, turning a potential crisis into a planned maintenance task.
2. Auto-Configuration for Bundled Tools: It would be a fantastic user experience if the update script could automatically adjust the configurations for its own bundled components. For example, if the script could auto-apply the necessary settings to Roundcube to handle the localhost TLS verification, it would ensure core tools work seamlessly post-update and save users significant diagnostic time.
3. Proactive "Heads-Up" in Documentation: Enhancing the release notes with a "Potential Issues & Fixes" section for common setups would be invaluable. Clear guides for predictable issues (like the Roundcube one this time) empower users to prepare in advance or resolve problems quickly, which builds great confidence in the update process.

We believe these measures would greatly enhance the user experience during major updates, fostering an even stronger sense of partnership between DirectAdmin and its user base.

Thank you for your amazing work and for considering our feedback.

 

[Ohm J]

Isn't php(mail) still working same as before ?
The change only affect SMTP or login as ({anyname}@domain) auth or you still found some issued with php(mail) ?

 

[Dettol]

Isn't php(mail) still working same as before ?
The change only affect SMTP or login as ({anyname}@domain) auth or you still found some issued with php(mail) ?

That's a great question, and the confusion is understandable because the change is subtle.

The answer is: No, the native PHP mail() function is no longer working as it did before, and this is a direct result of the new "Sender Address Spoofing Protection" introduced in DirectAdmin v1.680.

You are right that the changes affect SMTP, but they also specifically target and block the unauthenticated pathway that the mail() function uses.

• PHP mail() sends mail as a system user (e.g., 'apache') without logging into an email account. The new rules now block this.
• SMTP Auth requires logging in with a full email address and password before sending. This is now the only trusted method.

So, any script relying on the old mail() function will indeed fail. The solution is to switch to a library like PHPMailer that uses proper SMTP authentication.

Of course, their intention to enhance security is absolutely the right move and what we expect from mature software. It just would have been a much smoother transition for users if better supporting measures or a clearer migration path had been provided alongside the update.

 

[Ohm J]

Oh I see this change from 1.681.
So PHP mail() can send only if the mailbox or forwarder name exists from domain owner by the user otherwise it's reject.

 

[Ohm J]

pass test from 3 server ( no any customize ) with this code

<?php
$to = '{Some mail to}@gmail.com';
$from = '{Pick Any You Want}@{Your_Exists_Domain}';
$header = "FROM: MailTest <{$from}>". PHP_EOL
;
$message = "test message";
$subject = "test send id #". time();

mail($to,$subject,$message,$header, '-f '.$from.' -F "MailTest"') or die();

{Your_Exists_Domain} must owner by the user.

 

[Dettol]

pass test from 3 server ( no any customize ) with this code

<?php
$to = '{Some mail to}@gmail.com';
$from = '{Pick Any You Want}@{Your_Exists_Domain}';
$header = "FROM: MailTest <{$from}>". PHP_EOL
;
$message = "test message";
$subject = "test send id #". time();

mail($to,$subject,$message,$header, '-f '.$from.' -F "MailTest"') or die();

{Your_Exists_Domain} must owner by the user.

Hi Ohm J,

That's an excellent point, and you've likely hit on the exact technical reason why some of us are seeing phpmail() fail while others aren't. It seems to depend entirely on a new setting in exim.conf.

My understanding is that since DirectAdmin 1.680, there's a new default option:

block_sender_spoofing=yes

With this setting enabled (which is the new default for security), Exim blocks any mail that isn't sent through proper SMTP authentication. Since the native PHP mail() function sends as a system user without logging in, it gets blocked by this new rule.

So, if your phpmail() function is still working, it is highly probable that your server has been configured with block_sender_spoofing=no as a temporary workaround. This disables the new security feature and reverts to the old behavior.

This configuration difference is actually a great example of why I started this thread. A smoother, more clearly documented transition from DirectAdmin would help get everyone onto the same secure page without this confusion. The long-term solution, of course, is for us developers to adapt our code to use authenticated SMTP.

 

[Ohm J]

Since I already confirm from my post question, then I just leave without touch it.

No any "block_sender_spoofing" customize. And some test server just install from the last week.

But atleast the sender "domain" must owner by the user.

 

[Dettol]

Since I already confirm from my post question, then I just leave without touch it.

No any "block_sender_spoofing" customize. And some test server just install from the last week.

But atleast the sender "domain" must owner by the user.

Just check this out, most people are complaining

Thread 'DirectAdmin 1.680'

Jul 17, 2025

We are happy to announce the release of DirectAdmin 1.680.

A full release change log is here:

DirectAdmin 1.680​

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!

• sewiti
• Replies: 55
• Forum: DirectAdmin Version Updates

• 

 

[Ohm J]

They're complaining about SMTP, where's the complain about PHP mail ?

 

[Dettol]

They're complaining about SMTP, where's the complain about PHP mail ?

The complaint is about PHP mail because the new SMTP rules now apply to all outgoing mail, regardless of its origin. PHP mail() is simply one of the first victims of this new, stricter gatekeeping by the Exim SMTP server.

That's the key point of confusion, and the answer is simple: The new SMTP rules apply to everything.

Think of the Exim mail server as the single post office for the entire server. The new rule (block_sender_spoofing=yes) is like the postmaster declaring: "For security reasons, we no longer accept mail dropped anonymously into a mailbox. All letters must be handed over the counter by someone with a valid ID (i.e., a successful SMTP login)."

The native PHP mail() function is the equivalent of trying to drop a letter into that now-decommissioned mailbox. It fails not because the mail() function itself changed, but because the only exit point—the Exim SMTP server—now rejects any mail that doesn't come through its authenticated counter.

So, while the complaint might mention SMTP, the symptom is that unauthenticated methods like phpmail() are the first to break.