There's really no such thing as a "default" address when sending out mail.
The "default" address refers to "where does mail go if it's sent to an email address on a domain that isn't already defined." Thus, the term "default".
All email that is sent (every where, not just with DirectAdmin) has to have an
envelope-sender (sometimes called a
return-path, or bounce address, transactionally... it's the address used in the
MAIL FROM part of an SMTP transaction). Note that the
envelope-sender isn't necessarily the same thing as the
From: header included in emails (and often isn't).
The long and short of the difference between the
envelope-sender and the
From: header, is that the
From: header is only understood by the email application that an end-user is using. Strictly from an MTA to MTA transaction (one mail server to another mail server) it couldn't care less what is in the
From: header - or even if it exists, it only understands the
envelope-sender.
I suspect that you are referring to mail sent from the PHP
mail() function - which I believe requires at least 3 parameters - email address the message is sent to, the subject of the message, and the message itself - note that there's no requirement for a from or envelope-sender address. That's because, at least on Linux systems, this is automatically derived from the answer to "what system user ran this script?"
Take for example:
You have a script -
http://example.tld/mail.php
The user
example owns the
example.tld
And PHP is running as PHP-FPM, where execution of PHP script is piped through a socket owned by the system user
example.
The hostname of the server is
server1.myexample.tld
If the mail.php file uses the minimum 3 parameters and contains:
mail("[email protected]", "My Subject", "My Message");
Then by default (at least on all Linux servers that I am aware of) - the envelope sender of this message is going to be
[email protected]
If the mail.php file uses 4 parameters to add an extra header:
mail("[email protected]", "My Subject", "My Message", "From: [email protected]\r\n");
The
envelope-sender is still going to be
[email protected]. This means that if
[email protected] receives the email in their email application, it may say that the message is from
[email protected]. But if the mail server handling mail for
[email protected] - for whatever reason - rejects the message, then the message is going to bounce back to
[email protected].
If the mail.php file uses 5 parameters:
mail("[email protected]", "My Subject", "My Message", "From: [email protected]\r\n", "[email protected]");
This changes the
envelope-sender. The same situation plays out as if the message received by
[email protected] will likely show the message as coming from
[email protected] but if
[email protected]'s mail server rejects the message - again for whatever reason - then that bounce message is going to go to
[email protected].
(The
-f parameter is specific to sendmail... which Exim and I believe Postfix just copy. If you are using a different system, i.e. Windows, to run PHP - I don't know what MTA you may be using. Or if you happen to be using an MTA on Linux that doesn't copy this sendmail parameter, then this flag may be different)
The bottom line is that for any message that is sent out, HAS to have an
envelope-sender.
Technically... you could define a different email address to use as the
envelope-sender for all mail sent through PHP's
mail() function. But it's so far out in left-field that I'm not going to explain it. (It would involve modifying the
sendmail_path directive in the server-wide
php.ini file or defining this for each user). It would still beg the question, "what envelope-sender address are you going to use?" And it doesn't really solve anything.
Further from this... changing this for PHP
mail()'s function still won't affect any mail that is sent out from CGI scripts. Which follows the same scope as PHP's
mail() function just without the the fancy
mail() function.
If you have PHP's
mail() disabled and user's scripts are still being allowed to send out mail, then their either piping their mail out directly through the
sendmail binary, using a CGI script (which essentially is piping the mail out directly through the
sendmail binary), or connecting locally to the SMTP service.
Stopping users from piping directly through the
sendmail binary is going to be difficult. It would likely involve changing the group and permissions on the
/usr/sbin/exim binary, to prevent other users from being able to execute it. But that'd get very messy, probably won't hold, and will likely create more problems than it solves.
Preventing local users from accessing the SMTP service directly, the best way to do that would be to block this with
iptables or with
csf - enabling the
SMTP_BLOCK option and disabling the
SMTP_ALLOWLOCAL option in
/etc/csf/csf.conf. But this is going to have rammifications on webmail.
The BEST solution to all of this and the one that makes the most sense, is to find the account that is sending out mail through their scripts. If that's spam or for whatever reason you want to stop it, then tell those users and/or disable/suspend their account. I know in the past we had a TON of mail, spam mails, being sent out from our users scripts and most of this was all tied to users WordPress's having comments enabled and comments were either being emailed out for moderation or some other means. 99% of the WordPress users didn't use comments and had no idea that they were enabled. Whatever the case may be, finding the real source of the issue and resolving it there is going to be better than any attempt just trying to cover it up.
