It means that whether phpmail() works or not depends entirely on the
PHP handler your server uses:
- 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.
- 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.
PHP's mail() function - by default - will send mail by parsing it directly to the sendmail binary.
If you load up a phpinfo() page from your server and view it in a browser, look for
sendmail_path or
Path to sendmail This should be set to
/usr/sbin/sendmail -t -i If it's not, then that may be your issue.
What this is telling PHP is that calls to
mail() passes information directly to this command.
This means that when Exim picks up the message, it is passed through the
acl_not_smtp ACL in the exim.conf (which DirectAdmin names
acl_script).
Looking at this ACL in the exim.conf file, I don't see where
AUTH_BLOCK_SENDER_SPOOFING would have any bearing on the process.
You can see this by viewing the
/etc/exim.conf file and searching for
acl_script: to see what the entire ACL says.
The first thing it checks is to see if the user has sent too many messages. Now since you are using mod_php then every script - no matter the account - is going to get clumped into this. Every
mail() sent through mod_php is going to be sent by the user
apache. So if
user1 on your server sends 10 messages and
user2 on your server sends 100 messages, then
apache has now sent 110 messages. But if this is the case, you should be seeing:
User account (apache) has sent too many emails. Script delivery blocked.
in your exim_mainlog.
The next thing the ACL does is check to see if the user (again, this will always be
apache for mod_php setups) is listed in the
BLACKLIST_USERNAMES file - which would be
/etc/virtual/blacklist_usernames. Is
apache listed in
/etc/virtual/blacklist_usernames? Are any users listed in
/etc/virtual/blacklist_usernames?
If this is the case, you should be seeing:
User account (apache) is not allowed to send emails. Script delivery blocked via /etc/virtual/blacklist_usernames
in your exim_mainlog.
Next it checks to see if any user is blacklisted from sending mail through any scripts. These would be listed in the
/etc/virtual/blacklist_script_usernames. Is
apache or any other user listed in
/etc/virtual/blacklist_script_usernames?
If this is the case, you should be seeing:
User account (apache) is not allowed to send emails. Script delivery blocked via /etc/virtual/blacklist_script_usernames
in your exim_mainlog.
Next it checks to see if any of the recipients that the message is being sent to are for any domains that are currently suspended on the server. If it finds one, then the message is denied.
If this is the case, you should be seeing:
The domain ${domain} is currently suspended. Try later.
in your exim_mainlog. (${domain} would be any domain name).
That's really all the ACL checks for.
There are potential include files for this ACL found at:
/etc/exim.acl_script.pre.conf
/etc/exim.blockcracking/script.conf
/etc/exim.blockcracking/script.recipients.conf
Do you have anything in any of these files that might be hindering delivery of PHP
mail() messages?
I don't have any servers that use mod_php as the PHP handler, so I can't directly test any of this. But just looking through the flow of how messages are sent with PHP
mail() I don't see where
AUTH_BLOCK_SENDER_SPOOFING would have any affect on this.
If your PHP is configured to send mail using
mail() through an SMTP transaction, then that could definitely explain the issue you are seeing. But - as far as I'm aware - this is not a standard setup for PHP on Linux. On Windows, configuring PHP to use an SMTP transaction would be common (standard?) because Windows has no
sendmail (or exim) equivalent.
Additionally sending mail through the sendmail binary has a slight effect on a message deliverability. Because the message is not initially sent as an SMTP transaction as loses a lot of it's characteristics as a legitimate email message. (This is why you'll see a lot of guides or articles advising you to use PHPMailer to send emails from your PHP script, but that bypasses PHP's built-in
mail() function). You may have configured your PHP
mail() function to pass emails as an SMTP transaction (like a Windows server would do) in order to increase a message's deliverability. Unfortunately, I don't know what this PHP setup would look like since I don't have any servers configured like that.
A new message or response with subject: DirectAdmin has been updated to v1.680